pytest-django quiz

Test your pytest-django knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.

What does the `rf` (RequestFactory) fixture provided by pytest-django let a test do?

1. What does the `rf` (RequestFactory) fixture provided by pytest-django let a test do?
2. What is a general reason a Django project might specifically choose pytest-django over Django's own built-in test runner, given that both can ultimately run tests against the same Django application?
3. What is a benefit of using pytest's fixture system (via pytest-django) for setting up test data, compared to Django's traditional `setUp`/`tearDown` methods on a TestCase subclass?
4. How might a pytest-django test verify that a Django view correctly returns a 404 for a request to a genuinely nonexistent object (e.g. via `get_object_or_404`)?
5. Why might a Django project running pytest-django in CI want to also measure test coverage (via a plugin like pytest-cov)?
6. Why might pytest-django blocking database access by default (unless explicitly marked) be considered a useful design decision?
7. What is a reasonable general practice for organizing pytest-django tests to mirror a Django project's app structure (multiple Django apps within one project)?
8. What is the `client` fixture provided by pytest-django typically used for?
9. What is a reasonable use case for pytest-django integrating with a fixture-based factory library (like factory_boy) for generating Django model instances in tests?
10. What does the `django_db` marker (or fixture) provided by pytest-django allow a test to do?
11. How does pytest-django typically know which Django settings module to use when running tests?
12. Why might a team migrating from Django's built-in `TestCase`-based tests to pytest-django appreciate being able to write plain function-based tests instead of class-based ones?

More quizzes