factory_boy
factory_boy is a fixtures replacement based on thoughtbot’s factory_bot.
As a fixtures replacement tool, it aims to replace static, hard to maintain fixtures with easy-to-use factories for complex object.
Instead of building an exhaustive test setup with every possible combination of corner cases,
factory_boy
allows you to use objects customized for the current test,
while only declaring the test-specific fields:
class FooTests(unittest.TestCase):
def test_with_factory_boy(self):
# We need a 200€, paid order, shipping to australia, for a VIP customer
order = OrderFactory(
amount=200,
status='PAID',
customer__is_vip=True,
address__country='AU',
)
# Run the tests here
def test_without_factory_boy(self):
address = Address(
street="42 fubar street",
zipcode="42Z42",
city="Sydney",
country="AU",
)
customer = Customer(
first_name="John",
last_name="Doe",
phone="+1234",
email="john.doe@example.org",
active=True,
is_vip=True,
address=address,
)
# etc.
factory_boy is designed to work well with various ORMs (Django, Mongo, SQLAlchemy), and can easily be extended for other libraries.
Its main features include:
Straightforward declarative syntax
Chaining factory calls while retaining the global context
Support for multiple build strategies (saved/unsaved instances, stubbed objects)
Multiple factories per class support, including inheritance
Links
Documentation: https://factoryboy.readthedocs.io/
Repository: https://github.com/FactoryBoy/factory_boy
Mailing-list: factoryboy@googlegroups.com | https://groups.google.com/forum/#!forum/factoryboy
factory_boy supports Python 2.7, 3.4 to 3.6, as well as PyPy 2.7 and 5.8.
Download
PyPI: https://pypi.org/project/factory_boy/
$ pip install factory_boy
Source: https://github.com/FactoryBoy/factory_boy/
$ git clone git://github.com/FactoryBoy/factory_boy/
$ python setup.py install
Usage
Note
This section provides a quick summary of factory_boy features. A more detailed listing is available in the full documentation.
Defining factories
Factories declare a set of attributes used to instantiate an object.
The class of the object must be defined in the model
field of a class Meta:
attribute:
import factory
from . import models
class UserFactory(factory.Factory):
class Meta:
model = models.User
first_name = 'John'
last_name = 'Doe'
admin = False
# Another, different, factory for the same object
class AdminFactory(factory.Factory):
class Meta:
model = models.User
first_name = 'Admin'
last_name = 'User'
admin = True
Using factories
factory_boy supports several different build strategies: build, create, and stub:
# Returns a User instance that's not saved
user = UserFactory.build()
# Returns a saved User instance
user = UserFactory.create()
# Returns a stub object (just a bunch of attributes)
obj = UserFactory.stub()
You can use the Factory class as a shortcut for the default build strategy:
# Same as UserFactory.create()
user = UserFactory()
No matter which strategy is used, it’s possible to override the defined attributes by passing keyword arguments:
# Build a User instance and override first_name
>>> user = UserFactory.build(first_name='Joe')
>>> user.first_name
"Joe"
It is also possible to create a bunch of objects in a single call:
>>> users = UserFactory.build_batch(10, first_name="Joe")
>>> len(users)
10
>>> [user.first_name for user in users]
["Joe", "Joe", "Joe", "Joe", "Joe", "Joe", "Joe", "Joe", "Joe", "Joe"]
Realistic, random values
Demos look better with random yet realistic values; and those realistic values can also help discover bugs. For this, factory_boy relies on the excellent faker library:
class RandomUserFactory(factory.Factory):
class Meta:
model = models.User
first_name = factory.Faker('first_name')
last_name = factory.Faker('last_name')
>>> UserFactory()
<User: Lucy Murray>
Note
Use of fully randomized data in tests is quickly a problem for reproducing broken builds. To that purpose, factory_boy provides helpers to handle the random seeds it uses.
Lazy Attributes
Most factory attributes can be added using static values that are evaluated when the factory is defined, but some attributes (such as fields whose value is computed from other elements) will need values assigned each time an instance is generated.
These “lazy” attributes can be added as follows:
class UserFactory(factory.Factory):
class Meta:
model = models.User
first_name = 'Joe'
last_name = 'Blow'
email = factory.LazyAttribute(lambda a: '{0}.{1}@example.com'.format(a.first_name, a.last_name).lower())
date_joined = factory.LazyFunction(datetime.now)
>>> UserFactory().email
"joe.blow@example.com"
Note
LazyAttribute
calls the function with the object being constructed as an argument, when
LazyFunction
does not send any argument.
Sequences
Unique values in a specific format (for example, e-mail addresses) can be generated using sequences. Sequences are defined by using Sequence
or the decorator sequence
:
class UserFactory(factory.Factory):
class Meta:
model = models.User
email = factory.Sequence(lambda n: 'person{0}@example.com'.format(n))
>>> UserFactory().email
'person0@example.com'
>>> UserFactory().email
'person1@example.com'
Associations
Some objects have a complex field, that should itself be defined from a dedicated factories.
This is handled by the SubFactory
helper:
class PostFactory(factory.Factory):
class Meta:
model = models.Post
author = factory.SubFactory(UserFactory)
The associated object’s strategy will be used:
# Builds and saves a User and a Post
>>> post = PostFactory()
>>> post.id is None # Post has been 'saved'
False
>>> post.author.id is None # post.author has been saved
False
# Builds but does not save a User, and then builds but does not save a Post
>>> post = PostFactory.build()
>>> post.id is None
True
>>> post.author.id is None
True
ORM Support
factory_boy has specific support for a few ORMs, through specific factory.Factory
subclasses:
Django, with
factory.django.DjangoModelFactory
Mogo, with
factory.mogo.MogoFactory
MongoEngine, with
factory.mongoengine.MongoEngineFactory
SQLAlchemy, with
factory.alchemy.SQLAlchemyModelFactory
Debugging factory_boy
Debugging factory_boy can be rather complex due to the long chains of calls.
Detailed logging is available through the factory
logger.
A helper, factory.debug(), is available to ease debugging:
with factory.debug():
obj = TestModel2Factory()
import logging
logger = logging.getLogger('factory')
logger.addHandler(logging.StreamHandler())
logger.setLevel(logging.DEBUG)
This will yield messages similar to those (artificial indentation):
BaseFactory: Preparing tests.test_using.TestModel2Factory(extra={})
LazyStub: Computing values for tests.test_using.TestModel2Factory(two=<OrderedDeclarationWrapper for <factory.declarations.SubFactory object at 0x1e15610>>)
SubFactory: Instantiating tests.test_using.TestModelFactory(__containers=(<LazyStub for tests.test_using.TestModel2Factory>,), one=4), create=True
BaseFactory: Preparing tests.test_using.TestModelFactory(extra={'__containers': (<LazyStub for tests.test_using.TestModel2Factory>,), 'one': 4})
LazyStub: Computing values for tests.test_using.TestModelFactory(one=4)
LazyStub: Computed values, got tests.test_using.TestModelFactory(one=4)
BaseFactory: Generating tests.test_using.TestModelFactory(one=4)
LazyStub: Computed values, got tests.test_using.TestModel2Factory(two=<tests.test_using.TestModel object at 0x1e15410>)
BaseFactory: Generating tests.test_using.TestModel2Factory(two=<tests.test_using.TestModel object at 0x1e15410>)
Contributing
factory_boy is distributed under the MIT License.
Issues should be opened through GitHub Issues; whenever possible, a pull request should be included. Questions and suggestions are welcome on the mailing-list.
All pull request should pass the test suite, which can be launched simply with:
$ make test
In order to test coverage, please use:
$ make coverage
To test with a specific framework version, you may use a tox
target:
$ tox --listenvs
py27-django111-alchemy12-mongoengine015
py27-django20-alchemy12-mongoengine015
# ...
pypy3-django20-alchemy12-mongoengine015
examples
lint
$ tox -e py36-django20-alchemy12-mongoengine015
Valid options are:
DJANGO
forDjango
MONGOENGINE
formongoengine
ALCHEMY
forSQLAlchemy
To avoid running mongoengine
tests (e.g no mongo server installed), run:
$ make SKIP_MONGOENGINE=1 test
Contents, indices and tables
- Introduction
- Reference
- Using factory_boy with ORMs
- Common recipes
- Dependent objects (ForeignKey)
- Reverse dependencies (reverse ForeignKey)
- Simple Many-to-many relationship
- Many-to-many relation with a ‘through’
- Copying fields to a SubFactory
- Custom manager methods
- Forcing the sequence counter
- Converting a factory’s output to a dict
- Django models with GenericForeignKeys
- Fuzzy attributes
- Examples
- Internals
- ChangeLog
- 2.11.1 (2018-05-05)
- 2.11.0 (2018-05-05)
- 2.10.0 (2018-01-28)
- 2.9.2 (2017-08-03)
- 2.9.1 (2017-08-02)
- 2.9.0 (2017-07-30)
- 2.8.1 (2016-12-17)
- 2.8.0 (2016-12-17)
- 2.7.0 (2016-04-19)
- 2.6.1 (2016-02-10)
- 2.6.0 (2015-10-20)
- 2.5.2 (2015-04-21)
- 2.5.1 (2015-03-27)
- 2.5.0 (2015-03-26)
- 2.4.1 (2014-06-23)
- 2.4.0 (2014-06-21)
- 2.3.1 (2014-01-22)
- 2.3.0 (2013-12-25)
- 2.2.1 (2013-09-24)
- 2.2.0 (2013-09-24)
- 2.1.2 (2013-08-14)
- 2.1.1 (2013-07-02)
- 2.1.0 (2013-06-26)
- 2.0.2 (2013-04-16)
- 2.0.1 (2013-04-16)
- 2.0.0 (2013-04-15)
- 1.3.0 (2013-03-11)
- 1.2.0 (2012-09-08)
- 1.1.5 (2012-07-09)
- 1.1.4 (2012-06-19)
- 1.1.3 (2012-03-09)
- 1.1.2 (2012-02-25)
- 1.1.1 (2012-02-24)
- 1.1.0 (2012-02-24)
- 1.0.4 (2011-12-21)
- 1.0.2 (2011-05-16)
- 1.0.1 (2011-05-13)
- 1.0.0 (2010-08-22)
- Credits
- Credits
- Ideas