Basic Example of Usage¶
from django.db import models class Author(models.Model): name = models.CharField(max_length=255) class Book(models.Model): name = models.CharField(max_length=255) authors = models.ManyToManyField(Author)
from django.test import TestCase from django_dynamic_fixture import G class SearchingBooks(TestCase): def test_search_book_by_author(self): author1 = G(Author) author2 = G(Author) book1 = G(Book, authors=[author1]) book2 = G(Book, authors=[author2]) books = Book.objects.search_by_author(author1.name) self.assertTrue(book1 in books) self.assertTrue(book2 not in books)
pip install django-dynamic-fixture
1. Download zip file 2. Extract it 3. Execute in the extracted directory: python setup.py install
pip install -e email@example.com:paulocheque/django-dynamic-fixture.git#egg=django-dynamic-fixture
django-dynamic-fixture==<VERSION> # or use the development version git+git://github.com/paulocheque/django-dynamic-fixture.git#egg=django-dynamic-fixture
pip install django-dynamic-fixture --upgrade --no-deps
- Legacy: Django 1.2, 1.3 - Python: 2.7
- Django 1.4 with Python 2.7
- Django 1.5 with Python 2.7
- Django 1.6 with Python 2.7 or 3.3
- Not tested with Django 1.7 yet
List of features¶
- Highly customizable: you can customize fields recursively
- Deals with unique=True
- Deals with cyclic dependencies (including self references)
- Deals with many to many relationship (common M2M or M2M with additional data, i.e. through=’table’)
- Deals with custom fields (especially if the custom field inherits from a django field)
- Support for parallel tests
- Deals with auto calculated attributes
- It is easy to debug errors
- It is a terrible practice to use static data in tests.
- Creating dynamic fixture for each model is boring and it produces a lot of replicated code.
- It is a bad idea to use uncontrolled data in tests, like bizarre random data.
Comparison with other tools¶
The DDF was created in a context of a project with a very complex design with many cyclic dependencies. In that context, no available tool was satisfactory. Or we stumbled in some infinite loop or some bug caused by a custom field. For these reasons, the tests started to fail and it was very hard to understand why.
Another thing, the DDF was planned to have a lean and clean syntax. We believe that automated tests must be developed quickly with the minimum overhead. For that reason we are in favor of less verbose approach, except in the documentation ;)
Also, DDF is flexible, since it is possible to customize the entire data generation or by field.
- Either they are incomplete, or bugged or it produces erratic tests, because they use random and uncontrolled data.
- The syntax of others tools is too verbose, which polutes the tests.
- Complete, lean and practice documentation.
- It is hard to debug tests with another tools.
- List of other tools: <https://www.djangopackages.com/grids/g/testing/> or <http://djangopackages.com/grids/g/fixtures>
- The core of the tool is the algorithm, it is not the data generation as all other tools. This means you can change the data generation logic.
- Nose plugin that enables a setup for the entire suite (unittest2 includes only setups for class and module)
- Nose plugin to count how many queries are executed by test
- Command to count how many queries are executed to save any kind of model instance
- FileSystemDjangoTestCase that facilitates to create tests for features that use filesystem.