Speed up test_starttls.py::TestTLSEnding::test_eof_received#587
Conversation
cuu508
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #587 +/- ##
==========================================
+ Coverage 97.75% 97.78% +0.03%
==========================================
Files 23 23
Lines 5700 5698 -2
Branches 351 351
==========================================
Hits 5572 5572
+ Misses 79 77 -2
Partials 49 49 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| # I don't like this. It's too intimately involved with the innards of the SMTP | ||
| # class. But for the life of me, I can't figure out why coverage there fail | ||
| # intermittently. | ||
| # | ||
| # I suspect it's a race condition, but with what, and how to prevent that from | ||
| # happening, that's ... a mystery. |
There was a problem hiding this comment.
This seems like a part of the puzzle?
| # Some test cases need to .stop() the controller inside themselves | ||
| # in such cases, we must suppress Controller's raise of AssertionError | ||
| # because Controller doesn't like .stop() to be invoked more than once |
There was a problem hiding this comment.
Doesn't this refer to the thing you're removing? Are there any other in-test stops?
| # happening, that's ... a mystery. | ||
|
|
||
| # Entering portion of code where hang is possible (upon assertion fail), so | ||
| # we must wrap with "try..finally". |
There was a problem hiding this comment.
Have you checked git blame for clues?
It's possible that certain patch versions would reproduce it. Have you built like every Python 3.9.x with pyenv to confirm? This is likely hitting one of the cases that we don't test in CI or maybe something flaky that only happens under mysterious circumstances. Overall, the cleanup idea seems good, but I'd also like to hear a second opinion from @loqs at least.. |
2 participants
What do these changes do?
It fixes a 30 second delay in
aiosmtpd/tests/test_starttls.py::TestTLSEnding::test_eof_received.The contents of the test case was wrapped in
try ... finally, and thefinallyblock runstls_controller.stop(). Thefinallyblock is where the 30 seconds were spent.The
tls_controlleris prepared by a pytest fixture which also takes care of closing it so I suspect thefinallyblock was not doing anything useful anyway.After removing
try .. finallytests on all platforms still pass, and the 30 second delay is gone.Are there changes in behavior for the user?
No, it speeds up a single slow test.
Related issue number
Checklist
{py36,py37,py38,py39}-{nocov,cov,diffcov}, qa, docs{py36,py37,py38,py39}-{nocov,cov,diffcov}{py36,py37,py38,py39}-{nocov,cov,diffcov}, pypy3-{nocov,cov}, qa, docs{py36,pypy3}-{nocov,cov,diffcov}, qapy36-{nocov,cov,diffcov}, qa, docsNEWS.rstfile