Run tests in a module. Pytest testmod.py. Run tests in a directory. Pytest testing/ Run tests by keyword expressions. Pytest -k 'MyClass and not method' This will run tests which contain names that match the given string expression, which can include Python operators that use filenames, class names and function names as variables. Aug 27, 2021 If this checkbox is selected, Django test will run with the specified custom settings, rather than with the default ones. Specify the fully qualified name of the file that contains Django settings. You can either type it manually, in the text field to the right, or click the browse button, and select one in the dialog that opens.
Plug and play continuous integration with django and jenkins
There are a lot of ways to enable continuous integration with your django project. But most of them require a lot of time to configure and setup ci server and make changes in your django project.
This tutorial introduces a new way to enable continuous integration for django project, with minimal projects modifications by means of with django-jenkins.
Previously, ad-hoc integration django with jenkins required using nose testing frameworks instead of django native unittests. Since nose project uses custom test loader it leads to a lot of problems with django code - duplicate signals subscriptions, module loading and other test-only realted errors. Django-jenkins uses a standard unittest runner, so the code under test works like in production. No difference between django-jenkins run and manage.py test so keeps your hands free for real work.
Configuring django project¶
To enable django_jenkins you need only to add django_jenkins to INSTALLED_APPS in settings.py.
Running
will do the same job as
but also will create reports folder in the root of your django project with jenkins parsable pylint, test coverage and tests reports.
Django-jenkins have support for several other testing tools/ To enable it, you should include tools task to JENKINS_TASKS settings variable.
Please, note that corresponding task tool should be installed on jenkins server manually. Please refer to django-jenkins README for specific task dependencies list.
In order to get the right coverage, 'django_jenkins' app should be included as early as possible in INSTALLED_APPS
This tutorial doesn’t cover the library dependency management and deploying your django project on external server. Basically you could setup the CI server as you did in your local environment.
But if you prefer automatically installation and configuration dependencies on CI server, you could easily add virtalenv support for your project.
Add requirements to your requirements.txt file:
Running
will create local folder env with the required libraries for your project. Running those commands on other servers will help to sync the external dependencies.
Configuring jenkins¶
After a fresh Jenkins installation, you’ll need to install two required plugins:
- Violations plugin for parsing
pylintreports and - Cobertura Plugin for showing the code coverage.
Install these plugins via ManageJenkins->ManagePlugins->Available.
Start new job with creating free-style project:
After configuring the repository access, set up the build trigers. Poll SCM will run the build if any changes in repository are found. The line */5**** means checking repository every 5 minutes.
Select Addbuildstep->Executeshell. Add comands to setup environment and the run tests command
Specify the location of test reports - reports/TEST-*.xml and reports/lettuce.xml (in case you are using lettuce tests) files.
CHANGED in 0.13.0:: test reports from TEST-*.xml now stored in one file: junit.xml.
Configure locations of violations reports:
Test coverage reports are in reports/coverage.xml
That’s all!
Results¶
Press BuildNow and see what you’ve got:
Pylint and other lint tools reports for each builds, shows what warning/errors are new for each build.
Nice code coverage reports, showing the total coverage, and colored file listing.
And of course the test results and output.
Some developers regard writing tests as a lame checkbox task – but nothing could be farther from the truth. Done correctly, tests are one of your application’s most valuable assets.
The Django framework in particular offers your team the opportunity to create an efficient testing practice, based on the Python standard library unittest.
Proper tests in Django are fast to write, faster to run, and can offer you a seamless continuous integration solution for taking the pulse of your developing application.
With comprehensive tests, developers have higher confidence when pushing changes. I’ve seen firsthand in my own teams that good tests can boost development velocity as a direct result of a better developer experience.
In this article, I’ll share my own experiences in building useful tests for Django applications, from the basics to the best possible execution. If you're using Django or building with it in your organization, you might like to read my Django series on Victoria.dev.
What to test
Tests are extremely important. Far beyond simply letting you know if a function works, tests can form the basis of your team’s understanding of how your application is intended to work.
Here’s the main goal: if you hit your head and forgot everything about how your application works tomorrow, you should be able to regain most of your understanding by reading and running the tests you write today.
Here are some questions that may be helpful to ask as you decide what to test:
- What is your customer supposed to be able to do?
- What is your customer not supposed to be able to do?
- What should this method, view, or logical flow achieve?
- When, how, or where is this feature supposed to execute?
Tests that make sense for your application can help build developer confidence.
Django Test Client
With these sensible safeguards in place, developers make improvements more readily, and feel confident introducing innovative solutions to product needs. The result is an application that comes together faster, and features that are shipped often and with confidence.
Where to put tests
If you only have a few tests, you may organize your test files similarly to Django’s default app template by putting them all in a file called tests.py. This straightforward approach is best for smaller applications.
As your application grows, you may like to split your tests into different files, or test modules. One method is to use a directory to organize your files, such as projectroot/app/tests/. The name of each test file within that directory should begin with test, for example, test_models.py.
Besides being aptly named, Django will find these files using built-in test discovery based on the unittest module. All files in your application with names that begin with test will be collected into a test suite.
This convenient test discovery allows you to place test files anywhere that makes sense for your application. As long as they’re correctly named, Django’s test utility can find and run them.
How to document a test
Use docstrings to explain what a test is intended to verify at a high level. For example:
These docstrings help you quickly understand what a test is supposed to be doing. Besides navigating the codebase, this helps to make it obvious when a test doesn’t verify what the docstring says it should.
Docstrings are also shown when the tests are being run, which can be helpful for logging and debugging.
Run Django Tests Online
What a test needs to work
Django tests can be quickly set up using data created in the setUpTestData() method. You can use various approaches to create your test data, such as utilizing external files, or even hard-coding silly phrases or the names of your staff.
Personally, I much prefer to use a fake-data-generation library, such as faker.
The proper set up of arbitrary testing data can help you ensure that you’re testing your application functionality instead of accidentally testing test data. Because generators like faker add some degree of unexpectedness to your inputs, it can be more representative of real-world use.
Run Django Tests Positive
Here is an example set up for a test:
Tests pass or fail based on the outcome of the assertion methods. You can use Python’s unittest methods, and Django’s assertion methods.
For further guidance on writing tests, see Testing in Django.
Best possible execution for running your tests
Django’s test suite is manually run with:
I rarely run my Django tests this way.
The best, or most efficient, testing practice is one that occurs without you or your developers ever thinking, “I need to run the tests first.”
The beauty of Django’s near-effortless test suite set up is that it can be seamlessly run as a part of regular developer activities. This could be in a pre-commit hook, or in a continuous integration or deployment workflow.
I’ve previously written about how to use pre-commit hooks to improve your developer ergonomics and save your team some brainpower. Django’s speedy tests can be run this way, and they become especially efficient if you can run tests in parallel.
Tests that run as part of a CI/CD workflow, for example, on pull requests with GitHub Actions, require no regular effort from your developers to remember to run tests at all. I’m not sure how plainly I can put it – this one’s literally a no-brainer.
Testing your way to a great Django application
Tests are extremely important, and under-appreciated. They can catch logical errors in your application. They can help explain and validate how concepts and features of your product actually function. Best of all, tests can boost developer confidence and development velocity as a result.
Django Test Runner
The best tests are ones that are relevant, help to explain and define your application, and are run continuously without a second thought. I hope I’ve now shown you how testing in Django can help you to achieve these goals for your team!