7

I am new to pytest, I am running a very simple test to assert a model creation, but running the test seems to take a substantial amount of time. I have maybe 10 models tops, none of which are incredibly complicated.

4.67 setup
0.69s call
0.09s teardown

This is with adding the arguments (without the arguments it's over 30 seconds!): 

pytest --nomigrations --reuse-db

Am I doing something wrong? How do I decrease this setup time? Does setup time depend on number of models, something else? I can't imagine how long this will take once the app gets big. Any advise is welcome.

superdee
  • 637
  • 10
  • 23
  • 5 seconds is pretty much the par. Related Question/Answer: https://stackoverflow.com/questions/36487961/django-unit-testing-taking-a-very-long-time-to-create-test-database – metatoaster Aug 01 '18 at 02:22
  • Thanks for the response, glad I am not doing something wrong. For the most part, when developing and debugging, can I expect to wait 5 seconds between iterations (lets say restarting the debugger). Or is there a fast workaround here? – superdee Aug 01 '18 at 02:24
  • Depends how your application is structured. If the application can be structured in a way such that the business logic is decoupled from the model (i.e. a function that process some object which could be a model object or some kind of generic implementation), that business logic may be tested separately without invoking the entire model/setup framework, thus speeding up the entire test during development; the actual integration will still be needed but that will no longer be a strict requirement, and sporadic invocation before commit to repository should be sufficient. – metatoaster Aug 01 '18 at 02:37
  • @metatoaster That sounds ideally, especially if I just want to test a view functionality while I develop it. Is there a way I can tell pytest to forgo the setup step and basically treat it as if I was refreshing the page with a debugger running? – superdee Aug 01 '18 at 02:48
  • It's possible to just run a test file directly, i.e. `py.test some/package/tests/test_feature.py`, or `python -m unittest some.package.tests.test_feature` for the more generic option (which I personally prefer), however if you were to eschew portability/genericity of the base unittest framework, pytest specific extensions may be used: https://stackoverflow.com/questions/34833327/how-to-test-single-file-under-pytest – metatoaster Aug 01 '18 at 02:57
  • @metatoaster I should mention that I am using Django for all of this, perhaps that is why it is taking so long to setup? – superdee Aug 01 '18 at 03:03
  • This is why I generally don't develop directly on the platform in general, especially if the logic can be fully decoupled from any underlying pattern or framework. If this is the approach, a completely separate Python package may be created, and then the existing django project that need to integrate the logic can just simply import that package, and basic integration tests can be done at that point. Otherwise, bite the bullet and wait for tests to run (like I did when I developed on top of Plone, which was an even more heavy framework). – metatoaster Aug 01 '18 at 03:07
  • Not sure yours is the case, I previously ran into a slow startup and debugged to be an operating system slowliness on certain patterns of searched paths. You may use the same debug technique to find out. A fix was in pytest, not os. The reference: ["pytest very slow startup in cygwin"](https://stackoverflow.com/questions/30768254/pytest-py-test-very-slow-startup-in-cygwin). – minghua Aug 14 '20 at 16:00

0 Answers0