There are different kinds of tests. However, as a minimum, a programmer needs to know unit tests since they have to be able to write them. Unit testing checks the smallest testable part of an application. Integration testing checks whether these parts work well with each other.

The word unit is the key term here. Just test one unit at a time. Let's take a look at a simple example of a test case:

# tests.py 
from django.test import TestCase 
from django.core.urlresolvers import resolve 
from .views import HomeView 
class HomePageOpenTestCase(TestCase): 
    def test_home_page_resolves(self): 
        view = resolve('/') 
        self.assertEqual(view.func.__name__, 
                         HomeView.as_view().__name__) 

This is a simple test that checks whether the user is correctly taken to the home page view when they visit the root of our website's domain. Like most good tests, it has a long and self-descriptive name. The test simply uses Django's resolve() function to match the view callable mapped to the / root location to the known view function by their names.

It is more important to note what is not done in this test. We have not tried to retrieve the HTML content of the page or check its status code. We have restricted ourselves to test just one unit, that is, the resolve() function, which maps the URL paths to view functions.

Assuming that this test resides in, say, app1 of your project, the test can be run with the following command:

$ ./manage.py test app1 
Creating test database for alias 'default'... 
. 
----------------------------------------------------------------- 
Ran 1 test in 0.088s 
 
OK 
Destroying test database for alias 'default'... 

This command runs all the tests in the app1 application or package. The default test runner will look for tests in all modules in this package matching the test*.py pattern.

Django now uses the standard unittest module provided by Python rather than bundling its own. You can write a testcase class by subclassing from django.test.TestCase.

This class typically has methods with the following naming convention:

• test*: Any method whose name starts with test will be executed as a test method. It takes no parameters and returns no values. Tests will be run in
  alphabetical order.
• setUp (optional): This method will be run before each test method. It can be used to create shared objects or perform other initialization tasks that bring your test case to a known state.
• tearDown (optional): This method will be run after a test method, irrespective of whether the test passed or not. Clean-up tasks are usually performed here.

A test case is a way to logically group test methods, all of which test a scenario. When all the test methods pass (that is, do not raise any exception), the test case is considered passed. If any of them fail, the test case fails.