./csu test_suite will run the entire test suite. For running a specific tests, viewing code coverage, and more testing commands, see Helper Commands for Developing.
All tests are in the
tests/ directory, which in the
csunplugged/ directory (at the same level as the apps). It is structured as follows:
└── tests/ ├── general/ │ ├── management/ │ ├── templatetags/ │ ├── urls/ │ └── views/ ├── resources/ │ ├── loaders/ │ ├── models/ │ ├── resource/ │ ├── urls/ │ ├── views/ │ └── ResourcesTestDataGenerator.py ├── topics/ │ ├── loaders/ │ │ └── assets/ │ ├── models/ │ ├── urls/ │ ├── views/ │ └── TopicsTestDataGenerator.py ├── utils │ └── errors/ └── BaseTestWithDB.py
Note that each app being tested has it’s own folder, and this is then broken down further into the component being tested (i.e. views, urls, models, etc).
Items of interest from this diagram:
models/- contains a test file for each model in the app.
urls/- contains a test file for each url in the app.
views/- contains a test file for each view in the app.
loaders/- contains a test file for each loader in the app as well as an
assets/directory. Test yaml files should be saved in the corresponding loader directory within
assets/and should mimick the folder structure of the app where necessary.
Test Data Generators - these are classes used to generate place holder data in the database. You should use the methods in these files when testing a model that contains a foreign key and/or many-to-many field that needs to be populated.
BaseTestWithDB.py- this class inherits the Django
TestCaseclass, and creates and logs in a user. This is the base test class that all other tests should inherit from in order to interact with the database.
utils/errors/- contains test error classes for testing exceptions are raised correctly by the loaders.
When writing a new test function, it is important that the method name is as
descriptive as possible. The method name should also be prefixed with
as the test suite will only execute methods with this prefix.
We use Codecov to check the coverage of our tests. Every Pull Request should cover 100% of the difference (therefore increasing coverage), Travis will fail if this is not the case.