Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test-run-timeout doesn't work on multiprocess plugin #564

Open
kaichiachen opened this issue Mar 3, 2023 · 1 comment
Open

test-run-timeout doesn't work on multiprocess plugin #564

kaichiachen opened this issue Mar 3, 2023 · 1 comment
Labels

Comments

@kaichiachen
Copy link

Hi team,

I upgraded my nose2 to 0.12.0. Here is my unittest.cfg

[unittest]
plugins = nose2.plugins.mp

[multiprocess]
always-on = true
processes = 0
test-run-timeout = 1

I expected it will timeout the testcase if it runs over 1 sec
This is one of my test. I injected 10 secs sleep

    def test_sample(self):
        time.sleep(10)
        with self.assertRaises(ValueError):
            random.sample(self.seq, 20)
        for element in random.sample(self.seq, 5):
            self.assertTrue(element in self.seq)

And try to run nose2

#> nose2 -vvv -s ./example                                                                      
test_shuffle (example.test_example.TestSequenceFunctions) ... ok
test_choice (example.test_example.TestSequenceFunctions) ... ok
test_sample (example.test_example.TestSequenceFunctions) ... ok

----------------------------------------------------------------------
Ran 3 tests in 10.023s

OK

It runs over 1 sec and didn't report error. Could team help to check parameter test-run-timeout still works? thanks!

@sirosen sirosen added the docs label Apr 26, 2023
@sirosen
Copy link
Collaborator

sirosen commented Apr 26, 2023

I think this is actually a documentation issue, not a bug or regression. The test-run-timeout doesn't cause errors when reached -- and as far as I can tell, never did. It actually represents the amount of time spent waiting for workers to send info back to the main test process -- and if reached, the main process will loop and continue waiting.

That said... this is wonky, IMO. Looking at this parameter and expecting it to cause a failure makes perfect sense to me. I need to think through what the best next steps are, but at least part of it is to better document the current behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants