fuelen
SeedFactory - a toolkit for test data generation
The main idea of SeedFactory is to generate test data by calling your application’s business logic (context functions if you use Phoenix Contexts) instead of inserting directly into the database. This means your tests work with data that was created the same way it would be in production. SeedFactory resolves dependencies automatically, so you don’t need to worry about the details of preparing data that your test doesn’t directly care about.
Even in cases where calling business logic functions is impractical (e.g. for performance reasons), SeedFactory serves as a centralized hub for test data creation, ensuring a consistent approach across your test suite.
The library is completely agnostic to the database toolkit.
See the Overview section on GitHub and docs for details.
Feel free to ask any questions!
Trending in Announcing
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










First 6 of 6 Posts
LostKobrakai
This is great. I’ve tried a bunch of factory approaches, but this one feels quite well executed and seems to cover the needs I generally have quite well. I also really like that it makes it impossible to insert data in a way the codebase wouldn’t.
hauleth
That seems like super reasonable approach to factories. I already like that, however it feels a little bit macro heavy.
fuelen
Actually, command resolver can use whatever code you need. So, you can use something that differs from the actual implementation, like a simplified version of it. But the fact that it is placed in a single centralized place makes it very maintainable.
When I read your comment for the first time, I was surprised why do you think so, as there is only 1 macro – produce/1. Completely forgot that DSL for schema definition is built on macros
That’s because the heavy lifting is done by spark (@zachdaniel thank you for the library, support and quick bug fixing!)
I tried to describe the schema using simple structures in my initial implementation. But eventually, current implementation won.
fuelen
SeedFactory v0.6.0 has been released
fuelen
SeedFactory v0.7.0 Released
A big release with many internal changes
Same trait from multiple commands
The same trait can now be defined with different commands. This enables schemas that mirror real business logic where the same state can be reached through different paths:
Usage:
When multiple commands can produce the same trait, SeedFactory automatically picks one based on which commands can satisfy their dependencies without duplicating existing entities.
Compile-time validations
Schemas are now validated more thoroughly at compile time with helpful “did you mean?” suggestions in error messages.
Documentation
README now includes an “Advanced features” section covering
pre_exec/pre_produce,args_match/generate_args, and trail tracking.fuelen
SeedFactory v0.8.0 Released!
This release is focused on developer experience: better error reporting, improved documentation, and fewer dependencies.
Structured error reporting
When a command fails, you now get
SeedFactory.ExecErrorwith a visual execution plan showing what succeeded, what failed, and what was still pending:Execution history
Every
produce/execcall is now recorded in meta, providing a full audit trail of how a context was built. Combined with a compact inspect format, it’s easy to see what happened:Performance
Replaced
libgraphdependency with an inline topological sort, optimized compile-time trait indexing, and fixed quadratic list accumulation — fewer dependencies and faster compilation.