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

Review trial features for checking 'health' of... reactor, ...? #43

Open
altendky opened this issue Nov 21, 2018 · 4 comments
Open

Review trial features for checking 'health' of... reactor, ...? #43

altendky opened this issue Nov 21, 2018 · 4 comments

Comments

@altendky
Copy link
Member

It was suggested that trial provides various checks after each test (or each test class?) to verify the reactor is in a good state. Let's review those features and see how they can be applied. Perhaps a disable-able auto-use fixture?

@gregerspoulsen
Copy link

Has this been given any more thought?

I like pytest fixtures a lot, but I use trial.TestCase for most tests to make sure the reactor is left clean - I have had too many issues with leakage :'(

I would love to help if relevant.

@altendky
Copy link
Member Author

No, I have no thought about this at all. :[ Since you mentioned trial test cases I'll mention #93 as a heads up where trial+pytest>=5.4+pytest-twisted can result in reactor re-entrancy and significant confusion. Potentially directly relevant though would be #91. Potentially better fitting into the pytest plugin mechanisms would make a difference to adding this feature (or maybe not). If you would like to explain what it is that the trial test cases do to clean up or submit a proposal I would definitely appreciate it and read what you share.

@gregerspoulsen
Copy link

Yes, I ran into #93 when I upgraded last week and solved it by rolling back :)

To be honest I do not know exactly what happens underneath the hood (but will be happy to look into it). I do know the consequences though: If you have a scheduled delayedCall, uncaught errback or open socket it raises an error.

A small demo: trial_test.zip

This is useful for a couple of reasons:

  • you avoid accidentally having scheduled calls popping up in later tests which is difficult to debug
  • it detects bugs in the code where errors accidentally aren't caught

To someone new to twisted testing, it can be a real pain in the ass though - it is not always obvious how to clean up the reactor properly, particularly if you use 3rd party packages relying on twisted. But this is properly also where you learn some of the edges of your code...

@altendky
Copy link
Member Author

altendky commented May 1, 2020

Oh, I forgot about #4 (comment). Not as a full solution but rather as existing code related to identifying forgotten things.

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

No branches or pull requests

2 participants