This page needs a newer browser to run its tools. You can still read everything here.

Django Module 12

Testing Django applications interview questions

Interview questions on testing Django applications: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.

7 questions: 2 warm-ups and 5 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

Fresher

What is the difference between setUp() and setUpTestData()?

Answered in the lesson Testing with Django's test framework
Fresher

What does @pytest.mark.django_db do?

Answered in the lesson pytest-django, factories and coverage

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Mid to senior

A suite of 1,400 Django tests takes 11 minutes in CI. Most tests create a resident with a password and twenty notices in setUp(), then sign in with client.login(). Make it fast without making the tests depend on each other. What do you change first, and how do you show it helped?
What it tests

Measuring where test time goes, setUpTestData() and the isolation it keeps, the cost of password hashing, force_login(), and running tests in parallel safely.

First step

Measure before changing anything: run manage.py test with --timing and --durations 20, and profile one slow class. Then count what each test pays before its first assertion: here a password hash in create_user(), another in client.login(), and 21 rows, 1,400 times over.
Follow-ups
- What can break when setUp() becomes setUpTestData()?
- Is a fast password hasher in the test settings safe?
- When does --parallel help, and what must be true first?
From the lesson Testing with Django's test framework
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to senior

A view saves a booking inside atomic() and sends the confirmation email with transaction.on_commit(). Its TestCase test expected one email and failed, so a teammate changed the view to send the email directly, and the test passed. What is wrong with that, and how should the test be written?
What it tests

How TestCase's transactions interact with on_commit(), why side effects wait for a commit, and the tools that emulate a commit in tests.

First step

Explain why the test failed before touching the code: TestCase runs every test inside a transaction that is rolled back and never committed, so on_commit() callbacks never run there. The view was right and the test was wrong, so the change has to be undone.
Follow-ups
- How do you test that no email leaves when the booking fails?
- What does pytest-django offer for the same test?
- When is TransactionTestCase the better tool?
From the lesson Testing with Django's test framework
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Every billing test calls BillFactory(), whose SubFactory chain writes a society, an owner, a flat and the bill. The suite has 3,000 such tests and takes 9 minutes. Make it faster without making the tests harder to read.
What it tests

Seeing the hidden cost of sub-factories, choosing between build and create, sharing rows deliberately, and measuring before and after.

First step

Count what one test writes before guessing: capture the queries of a single BillFactory() call. Then sort the 3,000 tests by what they really need: saved rows, or only objects to read. Tests of pure logic need no database at all.
Follow-ups
- Which tests can switch to build(), and how do you find them?
- How do you share a flat between tests without coupling them?
- When is a factory the wrong tool?
From the lesson pytest-django, factories and coverage
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to staff

The billing app has 96 % coverage, and still a late-fee bug reached production: bills a few days late were charged double. How did the tests miss it, how do you use coverage to find such gaps, and what rule would you set for the team?
What it tests

The difference between code that ran and code that was checked, reading branch reports, assertions and mutation testing, and coverage rules that do not reward empty tests.

First step

Look at the report's missing column for the file of the bug, with branch coverage on, before discussing the percentage: a decision that only ever went one way shows there as a partial branch, even when every line ran.
Follow-ups
- Why did line coverage not show the gap?
- Would 100 % have prevented the bug?
- What does mutation testing add, and what does it cost?
From the lesson pytest-django, factories and coverage
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

The suite passes when run in one process. With pytest -n 8 a few tests fail, different ones on each run, and they pass when run alone. Find the cause and fix it.
What it tests

How parallel workers split a suite, the kinds of shared state that break isolation, and tools that make order dependence visible.

First step

Treat it as order dependence, not as a bug of pytest-xdist: run the suite in one process with a random or reversed order and see whether the same tests fail. Then list what tests share outside the database, which each worker gets on its own.
Follow-ups
- Which kinds of shared state break under parallel runs?
- Why do sequence values make tests fragile?
- How do you keep the suite isolated from now on?
From the lesson pytest-django, factories and coverage
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

All Django interview questions · The Django track

Warm-up questions

What is the difference between setUp() and setUpTestData()?

What does @pytest.mark.django_db do?

Questions with model answers

A suite of 1,400 Django tests takes 11 minutes in CI. Most tests create a resident with a password and twenty notices in setUp(), then sign in with client.login(). Make it fast without making the tests depend on each other. What do you change first, and how do you show it helped?

A view saves a booking inside atomic() and sends the confirmation email with transaction.on_commit(). Its TestCase test expected one email and failed, so a teammate changed the view to send the email directly, and the test passed. What is wrong with that, and how should the test be written?

Every billing test calls BillFactory(), whose SubFactory chain writes a society, an owner, a flat and the bill. The suite has 3,000 such tests and takes 9 minutes. Make it faster without making the tests harder to read.

The billing app has 96 % coverage, and still a late-fee bug reached production: bills a few days late were charged double. How did the tests miss it, how do you use coverage to find such gaps, and what rule would you set for the team?

The suite passes when run in one process. With pytest -n 8 a few tests fail, different ones on each run, and they pass when run alone. Find the cause and fix it.