The AutoFixture registry

Since AutoFixture is designed to fit for almost all models, its very generic and doesn’t know anything about the actual logic and meanings of relations or the purpose of your model fields. This makes it sometimes a bit difficult to provide the correct field_values in all places where you want autofixture to instanciate your models.

So there is a registry to register custom AutoFixture subclasses with specific models. These subclasses are then used by default if you generated test data either with the loadtestdata management command or with one of the shortcuts in autofixture.

autofixture.register(model, autofixture, overwrite=False, fail_silently=False)

Register a model with the registry.

Arguments:

model can be either a model class or a string that contains the model’s app label and class name seperated by a dot, e.g. "app.ModelClass".

autofixture is the AutoFixture subclass that shall be used to generated instances of model.

By default register() will raise ValueError if the given model is already registered. You can overwrite the registered model if you pass True to the overwrite argument.

The ValueError that is usually raised if a model is already registered can be suppressed by passing True to the fail_silently argument.

autofixture.unregister(model_or_iterable, fail_silently=False)

Remove one or more models from the autofixture registry.

Default AutoFixture subclasses

There are some AutoFixture subclasses that are shipped by default with django-autofixture. These are listed below.

class autofixture.autofixtures.UserFixture(*args, **kwargs)

UserFixture is automatically used by default to create new User instances. It uses the following values to assure that you can use the generated instances without any modification:

• username only contains chars that are allowed by django’s auth forms.
• email is unique.
• first_name and last_name are single, random words of the lorem ipsum text.
• is_staff and is_superuser are always False.
• is_active is always True.
• date_joined and last_login are always in the past and it is assured that date_joined will be lower than last_login.

__init__(*args, **kwargs)

By default the password is set to an unusable value, this makes it impossible to login with the generated users. If you want to use for example autofixture.create_one('auth.User') in your unittests to have a user instance which you can use to login with the testing client you can provide a username and a password argument. Then you can do something like:

autofixture.create_one('auth.User', username='foo', password='bar`)
self.client.login(username='foo', password='bar')