TestCase and SimpleTestCase in Django - Step-by-Step Execution

Concept Flow - TestCase and SimpleTestCase

Start Test Run

↓

Choose Test Class

↓

TestCase

↓

Setup DB

↓

Run Tests

↓

Teardown DB

↓

Report Results

Tests start by choosing between TestCase (with database setup) or SimpleTestCase (without DB). Then tests run, and results are reported.

Execution Sample

Django

from django.test import TestCase, SimpleTestCase

class MyTest(TestCase):
    def test_add(self):
        self.assertEqual(1 + 1, 2)

This code runs a database-backed test checking if 1 + 1 equals 2.

Execution Table

Step	Action	Test Class	Database Setup	Test Run	Result
1	Start test run	-	No	No	-
2	Select test class	MyTest (TestCase)	Prepare test DB	No	-
3	Setup database	MyTest (TestCase)	Test DB ready	No	-
4	Run test_add method	MyTest (TestCase)	Test DB ready	Run test_add()	Pass
5	Teardown database	MyTest (TestCase)	Remove test DB	Tests done	-
6	Report results	-	No	All tests passed	Success
7	End test run	-	No	No	-

💡 All tests completed, database cleaned up, results reported.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
Database	Not ready	Ready	Ready	Removed	Not ready
Test Result	None	None	Pass	Pass	Pass

Key Moments - 2 Insights

Why does TestCase set up and tear down a test database but SimpleTestCase does not?

TestCase runs tests that need database access, so it prepares a test database before tests and removes it after (see execution_table steps 2-5). SimpleTestCase is for tests without database needs, so it skips this setup.

What happens if a test in TestCase modifies the database?

Each test runs inside a transaction that is rolled back after the test, so changes do not affect other tests. This isolation is part of the database setup and teardown shown in steps 3 and 5.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the test database prepared?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Database Setup' column in the execution_table rows.

According to the variable tracker, what is the database state after step 5?

A Ready

B Not ready

C Removed

D Unknown

💡 Hint

Look at the 'Database' row in variable_tracker after step 5.

If you use SimpleTestCase instead of TestCase, what changes in the execution flow?

A Database setup and teardown steps are skipped

B Tests run slower due to database overhead

C Tests cannot run at all

D Test results are not reported

💡 Hint

Refer to the concept_flow diagram showing separate paths for TestCase and SimpleTestCase.

Concept Snapshot

TestCase runs tests with a test database setup and teardown.
SimpleTestCase runs tests without database setup.
Use TestCase for tests needing database access.
Use SimpleTestCase for fast tests without DB.
Each TestCase test runs isolated with DB rollback.
Results are reported after all tests finish.

Full Transcript

In Django testing, TestCase and SimpleTestCase are two base classes for writing tests. TestCase prepares a test database before running tests and cleans it up after, ensuring tests that need database access run safely and isolated. SimpleTestCase skips database setup for faster tests that don't need the database. The execution flow starts by selecting the test class, then if TestCase is used, the test database is prepared. Tests run, and results are recorded. After tests finish, the database is torn down. Variables like the database state and test results change during these steps. Key points include understanding why TestCase manages the database and how it isolates tests. Visual quizzes help check understanding of when the database is ready and differences between the two classes.

Practice

1. Which Django test class should you use when your test needs to access the database?

easy

A. StaticLiveServerTestCase

B. TestCase

C. SimpleTestCase

D. TransactionTestCase

Solution

1. Step 1: Understand the purpose of TestCase

   TestCase is designed for tests that require database access and setup.

2. Step 2: Compare with SimpleTestCase

   SimpleTestCase is used when no database interaction is needed.

3. Final Answer:

   TestCase -> Option B

4. Quick Check:

   Database tests = TestCase [OK]

Hint: Use TestCase if your test touches the database [OK]

Common Mistakes:

• Using SimpleTestCase for database tests
• Confusing TransactionTestCase with TestCase
• Assuming SimpleTestCase can access the database

2. Which of the following is the correct way to import SimpleTestCase in a Django test file?

easy

A. from django.test import SimpleTestCase

B. import SimpleTestCase from django.test

C. from django.test.simple import SimpleTestCase

D. from django.test import simpletestcase

Solution

1. Step 1: Recall Django test imports

   Django provides SimpleTestCase in the django.test module.

2. Step 2: Check syntax correctness

   Correct Python import syntax is from module import ClassName.

3. Final Answer:

   from django.test import SimpleTestCase -> Option A

4. Quick Check:

   Correct import syntax = from django.test import SimpleTestCase [OK]

Hint: Use 'from django.test import SimpleTestCase' to import [OK]

Common Mistakes:

• Using wrong import syntax
• Trying to import from non-existent submodules
• Incorrect capitalization in import statements

3. What will be the output when running this test code?

from django.test import SimpleTestCase

class MyTests(SimpleTestCase):
    def test_addition(self):
        self.assertEqual(2 + 3, 5)

    def test_database(self):
        from myapp.models import Item
        self.assertEqual(Item.objects.count(), 0)

medium

A. Both tests pass successfully

B. Both tests fail

C. test_addition passes, test_database raises an error

D. test_addition fails, test_database passes

Solution

1. Step 1: Analyze SimpleTestCase behavior

   SimpleTestCase does not set up the database, so database queries will fail.

2. Step 2: Check each test method

   test_addition is a simple math check and will pass. test_database tries to query the database, causing an error.

3. Final Answer:

   test_addition passes, test_database raises an error -> Option C

4. Quick Check:

   SimpleTestCase blocks DB access = test_addition passes, test_database raises an error [OK]

Hint: SimpleTestCase blocks DB; DB queries cause errors [OK]

Common Mistakes:

• Assuming SimpleTestCase allows database queries
• Expecting all tests to pass
• Ignoring import errors from models

4. You wrote a test class inheriting from TestCase but your tests fail with errors about database access. What is a likely cause?

medium

A. You forgot to run migrations before testing

B. You used SimpleTestCase instead of TestCase

C. You did not import TestCase correctly

D. Your test methods are missing the self parameter

Solution

1. Step 1: Understand database setup in tests

   TestCase requires the test database to be migrated before running tests.

2. Step 2: Identify common causes of DB errors

   Failing to run migrations causes database errors even if TestCase is used.

3. Final Answer:

   You forgot to run migrations before testing -> Option A

4. Quick Check:

   DB errors often mean missing migrations [OK]

Hint: Run migrations before tests using TestCase [OK]

Common Mistakes:

• Confusing SimpleTestCase with TestCase
• Ignoring migration commands
• Missing self in test method signatures

5. You want to write tests that check both simple logic and database queries in your Django app. How should you organize your test classes?

hard

A. Use TestCase for logic tests and SimpleTestCase for database tests

B. Use only SimpleTestCase for all tests

C. Use only TestCase for all tests

D. Use SimpleTestCase for logic tests and TestCase for database tests

Solution

1. Step 1: Separate tests by database need

   Logic-only tests do not need database setup, so SimpleTestCase is faster and sufficient.

2. Step 2: Use TestCase for database tests

   Tests that query or modify the database require TestCase to set up the test database.

3. Final Answer:

   Use SimpleTestCase for logic tests and TestCase for database tests -> Option D

4. Quick Check:

   Split tests by DB need: SimpleTestCase vs TestCase [OK]

Hint: Use SimpleTestCase for logic, TestCase for DB tests [OK]

Common Mistakes:

• Using TestCase for all tests unnecessarily
• Trying to run DB tests with SimpleTestCase
• Mixing test types in one class