search

idlesign / pytest-djangoapp

Nice pytest plugin to help you with Django pluggable application testing.
https://github.com/idlesign/pytest-djangoapp
BSD 3-Clause "New" or "Revised" License
40 stars 6 forks source link

pytest-django #1

Open blueyed opened 5 years ago

blueyed commented 5 years ago

Hi, just found this plugin, and read this in the README:

What about pytest-django

It uses setuptools entrypoints feature for pytest plugin discovery. It's not a problem by itself, but all kinds of bootstrapping with side effects made by pytest-django just on startup, make the plugin a poor choice for cases of system-wide (i.e. not venv) installations.

Can you elaborate on this? Do you mean that pytest-django gets used always when installed systemwide? (there would be -p no:django to disable it)

Philosophy that next to no unit test should require DB access may be quite annoying.

I found this very useful, especially with new projects - where it showed more than once that some validation could/should be done before any DB access.

And it is easy to work around by having e.g. an auto-use fixture that requests db. But maybe also adding an option for this might be worth it, not sure. Typically you end up using fixtures, which then just themselves request db already.

idlesign commented 5 years ago

Hi,

Do you mean that pytest-django gets used always when installed systemwide? (there would be -p no:django to disable it)

That's it. You see, I maintain a number of Django apps alongside with non Django related applications. In such a case installing pytest-django system wide seems useful but testing non-Django related apps leads to a forementioned side effects with wierd tracebacks. -p workaround would require me to adopt that option in config in an unrelated project. Why should I bother?

I found this very useful, especially with new projects - where it showed more than once that some validation could/should be done before any DB access.

That would depend on an approach. I prefer thick models: if a feature clearly belongs to a certain model and only to it, there's no reason to factor it out (except maybe for test, but writing code for tests instead of writing tests for code, it's not what I want to do). It seems unfortunate that pytest-django would require to mark a test with db even if a model method under test doesn't perform any db hit at all.

And it is easy to work around by having e.g. an auto-use fixture that requests db. But maybe also adding an option for this might be worth it, not sure.

Once again the workaround is known, but why should I workaround at all. I would rather prefer a mark to ensure that there are no db hits in certain test than vice versa.

To wrap it up: taking aside fixtures, it's design decisions and scaffolding features (useful for testing mainly reusable apps rather than Django projects as a whole) that differ pytest-djangoapp from pytest-django.

blueyed commented 5 years ago

Thanks for your clarifications.

It seems unfortunate that pytest-django would require to mark a test with db even if a model method under test doesn't perform any db hit at all.

That shouldn't be the case, i.e. it only blocks DB connections really - not models in general. (But depending on the methods used there you might actually use the DB connection then.)