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.
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.
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.
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:
command :create_user do
# ... creates user with status: :pending
produce :user
end
command :activate_user do
param :user, entity: :user, with_traits: [:pending]
# ... updates user to status: :active
update :user
end
command :create_active_user do
# ... creates user with status: :active directly
produce :user
end
# :active can be reached via transition...
trait :active, :user do
from :pending
exec :activate_user
end
# ...or directly
trait :active, :user do
exec :create_active_user
end
# Unique marker for the direct path
trait :pending_skipped, :user do
exec :create_active_user
end
Usage:
# SeedFactory picks the first declared command by default
produce(ctx, user: [:active])
# Force a specific path using a trait unique to that command
produce(ctx, user: [:active, :pending_skipped])
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.
Every produce/exec call 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:
Replaced libgraph dependency with an inline topological sort, optimized compile-time trait indexing, and fixed quadratic list accumulation — fewer dependencies and faster compilation.
That’s because the heavy lifting is done by 
