After working using the factory_boy library for over 3 years on a Django monolith containing +230 tables, +2200 relevant files, and +75k relevant lines of code, I’ve collected and listed all my biggest learnings.
In this presentation, I try to share some of my experiences, showing what I consider to be good practices in using factory_boy in complex systems.
- A short introduction of myself factory_boy: what is it? - the definition and the purpose of the tool
- Example application - a quick overview of the application we will use to demonstrate the best practices
- How to install factory_boy
- How to use factory_boy
- Best Practices:
- Factories must represent their models
- Do not rely on defaults from factories
- Factories must have only the required data. if the field is nullable -> under traits.
- Build over create
- If FK is in the table -> SubFactory. If FK is in the other table -> RelatedFactory + trait
- Fixtures only to wrap factories in the test file
- Avoid using fixtures on shared files like conftest
- Wrapping up
talk talk djangocon djangocon-us documentation factory_boy open-source python tests