1. Django Test Runner
2. Django Test Runner Settings
3. Django Nose Test Runner
4. Django Test Client
5. Django Unit Test
6. Django Transactiontestcase

After you’ve written some tests for your Django app, and gotten them all topass, you may wonder “Do I have enough tests? Am I missing anything?” One way tohelp yourself answer that question is to measure the coverage of yourtests–that is, how thoroughly your tests exercise the application’s code.

Django test runner not finding tests. Ask Question Asked 11 years, 8 months ago. Active 18 days ago. Viewed 45k times 87 18. I am new to both Python and Django and I. Django 2.2 documentation. Django.test.runner; Getting help FAQ Try the FAQ — it's got answers to many common questions. Index, Module Index, or Table of Contents Handy when looking for specific information. Django-users mailing list Search for information in the archives of the django-users mailing list, or post a question. Adds support for running Django tests in Visual Studio Code. Provides shortcuts to run closest method, class, file, app and previous tests. Provides support for Django-Nose in settings. Draws inspiration from vscode-django-tests and vim-python-test-runner. This VS Code extension gives quick access to running Django tests by invoking python manage.py test with the VS Code action Django Test Runner: Run Tests or a keyboard shortcut. This will run tests in a VS Code terminal. You can optionally display the status of tests by configuring an XMLRunner test report.

Perhaps the most popular tool for measuring coverage in Python is simply calledcoverage. While your tests are running, it keeps track of which lines ofapplication code are executed, which ones are skipped (like comments), and whichones are never reached. At the end, it spits out a report that indicates whichlines of code were not executed–this points directly to holes in your testcoverage.

The nose testing tool integrates nicely with coverage, and django-nose tiesit all into Django. This chapter will give an overview of how to get it working.

Configure django-nose¶

The first thing to do is install django-nose using pip:

Then make these additions to your project’s settings.py:

Here, we’re setting a couple of command-line arguments to be included every timewe run pythonmanage.pytest. The --with-coverage option says we want acoverage report, and the --cover-package option lists all of the modules weare hoping to cover (these are the names of your Django apps). For a completelist of other available options, run pythonmanage.pyhelptest.

Django Test Runner

Coverage reports¶

When running test cases with coverage enabled, a report is printed at the endlooking something like this:

This says the foo.models module has 30 lines of executable code, and 5 ofthose lines were not evaluated during testing. The specific lines that aren’tcovered are listed at the end.

Why would certain lines not be executed? Perhaps those lines define a functionthat was never called, which means we need to add some tests for that function.Maybe those lines are inside an if/else block that only executed theif part, so we need to add tests for the else part also. It could be anexception handler that never encountered an exception, in which case we couldadd tests that purposely cause that exception (and verify that the correctexception was raised).

Try adding the --cover-html option to your NOSE_ARGS if you’d like anice HTML report that highlights the missing lines in your source code.

Django Test Runner Settings

Unreachable code¶

It’s possible (though rare) that some lines of code are missed because they aresimply unreachable. For example, the line inside this if statement can neverbe executed:

Django Nose Test Runner

Or, have you ever seen code like this?:

With sufficient testing and coverage analysis, you can determine withnear-certainty whether “This should never happen” is a true statement. If thereis no possible way for do_something(x) to raise SomeError, then there’sno reason to keep the extra code around.

Further reading¶

Django Test Client

So far, what you’re getting out of this is statement coverage, which is themost basic kind of code coverage, and also arguably the weakest. It only tellsyou which lines of code were evaluated, but it does not tell you anything aboutall the possible ways that each of those lines could be evaluated. Thosealternatives can be measured using branch and condition coverage, which isbeyond the scope of this example.

Django Unit Test

Statement coverage is a good first step, and can point you towards obvious gapsin your test suite. It may be insufficient in the long run, but it’s the easiestplace to start if you’ve never measured coverage before.

Django Transactiontestcase

See What is Wrong with Statement Coverage for more insight, and refer toTest coverage analysis for a Python-specific introduction to more detailedcoverage techniques.