What it does¶
Django testmaker is an application that writes tests for your Django views for you. You simply run a special development server, and it records tests for your application into your project for you. Tests will be in a Unit Test format, and it will create a separate test for each view that you hit.
Step 1: Add test_utils to your INSTALLED_APPS settings.
./manage.py testmaker -a APP_NAME
This will start the development server with testmaker loaded in. APP_NAME must be in installed apps, and it will use Django’s mechanism for finding it. It should look a little something like this:
eric@Odin:~/EH$ ./manage.py testmaker mine Handling app 'mine' Logging tests to /home/eric/Python/EH/mine/tests/mine_testmaker.py Appending to current log file Inserting TestMaker logging server... Validating models... 0 errors found Django version 1.0.1 final, using settings 'EH.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
Then, as you browse around your site it will create unit test files for you, outputting the context variables and status code for each view that you visit. The test file used is in APP/tests/APP_testmaker.py. Once you have your tests written, you simply have to add them into your __init__.py, and then run your tests.
./manage.py test -a APP_NAME
Testmaker Internal Basics¶
Testmaker now has a pluggable backend architecture. It includes the concept of a Processor and a Serializer. A Serializer is responsible for serializing your request and responses, so that they can be run again later. A Processor is response for taking these request and response objects and turning them into the actual Unit Tests.
Both processors and serializers follow the standard API direction that django serializers started. For example, to grab instances of both of them, use the following code:
serializer = serializers.get_serializer('pickle')() processor = processors.get_processor('django')()
Testmaker ships with 2 default serializers currently. They are the json and pickle backends.
Testmaker currently ships with just one Processor, the django processor, which produces Django Testcase-style Unit Tests.
Adding a new backend for a Processor or Serializer is easy. They both provide a similar interface, which can be located in the base.py file in their respective directories.
The only two functions that are required for each backend are the ability to save a request and a response. They have obvious defitions, and you should look in their directory for examples.
save_response(self, request, response)¶
If you pass the -f option to testmaker, it will create fixtures for you. They will be saved in APP/fixtures/APP_fixtures.FORMAT. The default format is XML because I was having problems with JSON.
Pass this in with a valid serialization format for Django. Options are currently json, yaml, or xml.
This allows you to pass in the normal address and port options for runserver.
Force app filtering¶
I plan on having an option that allows you to restrict the views to the app that you passed in on the command line. This would inspect the URLConf for the app, and only output tests matching those URLs. This would allow you to fine tune your tests so that it is guaranteed to only test views in the app.
Better test naming scheme¶
The current way of naming tests is a bit hackish, and could be improved. It works for now, and keeps names unique, so it’s achieving that goal. Suggestions welcome for a better way to name things.