Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article uses pytest - does anyone have similar tips when using pythons builtin unittest?


The sys.monitoring and import optimisation suggestions apply as-is.

If you use standard unittest discovery the third item might apply as well, though probably not to the same degree.

I don’t think unittest has any support for distribution so the xdist stuff is a no.

On the other hand you could use unit test as the API with Pytest as your test runner. Then you can also use xdist. And eventually migrate to the Pytest test api because it’s so much better.


I wwsn't familiar with this sys.monitoring option for coverage. Going to give it a try in my test suite. At the moment with docker testcontainers, gh actions test matrix for multiple python versions, and unit + regression + integration tests it is taking about 3-5 minutes.


Warning, there is a change in coverage 7.7.0 that disables sysmon support for coverage if using branch coverage _and_ a version of Python before 3.14alpha6.

[0]: https://coverage.readthedocs.io/en/7.8.0/changes.html#versio...


Ah, thank you! I think you just saved me some time!


I profiled a huge legacy tests collection using cProfile, and found lots of low hanging fruits. Like some tests were creating 4000x3000 Pillow image in memory just to test how image saving code works (checkign that filename and extension are correct). And hundreds of tests had created this huge image for every test (in the setUp method) because of unittest reliance on inheritance. Reducing size image to 10x5 made the test suite faster for like 5-7% (it was long time ago, so I don't remember exact statistics).

So, I'd run the tests under cProfile first.


But the changes in TFA were of the other of 75% improvement for "dumb" changes that were agnostic to the details of the tests being run.

Saying you got a 5-7% improvement from a single change, discovered using the profiler, that took understanding of the test suite and the domain to establish it was OK, and that actually changed the functionality under test - that's all an argument for doing exactly the opposite of what you recommend.


> that actually changed the functionality under test - that's all an argument for doing exactly the opposite of what you recommend.

It was an old functionality. Someone wrote a super class that for the need of testing filesystem functionality created extremely large images. Not only there was no need to test with such large images, other developers eventually inherited more testcases from that setup code (because there were other utility methods), and now setUp code was needlessly creating images that no test used.

Generating a huge 4k image takes a significant time using Pillow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: