https://pantsbuild.org/ logo
Join Slack
Powered by
Hey, when using `pants test ::` for testing django...
# general
h
Hey, when using 
pants test ::
for testing django the performance is much worse than just using 
pytest
. 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
[pytest]
lockfile = "lockfiles/python/tools/pytest"
version = "pytest>=7.1.2,<7.2"
extra_requirements.add = [
  "pytest-django==4.5.2",
  "pytest-icdiff==0.5",
  "mixer==7.2.1"
]
w
hey! sorry for the trouble.
is 
pantsd
staying up between runs? and are any files being invalidated?
to check that, look at 
.pants.d/pants.log
, 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 
::
)
e
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
h
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
h
Sorry for the inconvenience but it was my fault. I used debug=True, so caching and parallelism was disabled.
h
aha
how is the performance without that?
9 Views
Open in Slack
PreviousNext
Powered by