Hey, when using `pants test ::` for testing django...
# general
Hey, when using
pants test ::
for testing django the performance is much worse than just using
. Each test takes 8.5-9.5 secs (constantly) , because of some pants setup I think. Using pytest most of the tests run in under one second. I thought pants could run tests in parallel but only one core out of 4 is used. Maybe I am doing something wrong. Also caching seems not to work: When rerunning tests (without changing any files inbetween) every tests gets called again, not only the ones that failed. Is this because I am using a development version of pants or a configuration error? PANTS_SHA: f721c1077f97ef1aacba2a093f3f5cfd9677dc75
Copy code
lockfile = "lockfiles/python/tools/pytest"
version = "pytest>=7.1.2,<7.2"
extra_requirements.add = [
hey! sorry for the trouble.
staying up between runs? and are any files being invalidated?
to check that, look at
, which will report restarts and which files are being invalidated
files changing will be reported in the log, and could explain why your tests need to re-run
but they will still only miss the cache if the file content (according to SHA256) has changed
finally, to isolate the issue, i’d suggest starting by running a single test at a time:
./pants test $file
(rather than
If pantsd is up and fine, another potential culprit is expensive pytest session scoped fixtures, which, under pants, are no longer doing what you'd hope.
👍 1
Yeah, those make sense in Django tests (setting up dbs and so on)
This is where supporting batching tests in fewer pytest runs is going to be really important for performance
Sorry for the inconvenience but it was my fault. I used debug=True, so caching and parallelism was disabled.
how is the performance without that?