elixirs/faker: fake data generation for Elixir test suites
Faker is a pure Elixir library for generating fake data.
At a glance
- What is it?
- Faker is a pure Elixir library that generates fake values for tests and seed data. It is small, MIT licensed, and designed to be started explicitly in your test helper, but its README leaves the actual data modules and locale behaviour mostly to the hexdocs.
- Who is it for?
- Adopt Faker if you write Elixir tests or seed scripts that need plausible names, addresses, or other fake values without a fixture file, and if you are willing to read hexdocs.pm/faker because the README only points there. Do not adopt it if you need guaranteed deterministic output across library versions, since locale data and generator internals can change between releases.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Elixir, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Faker fills in an Elixir test setup
Elixir projects that touch a database usually need rows that look real enough for assertions, screenshots, or manual QA. Hand-written fixture files work until the schema changes, at which point every fixture has to be edited by hand. Faker takes the other route: call a function, get a value. The README describes it as a pure Elixir library for generating fake data, and the dependency line it recommends is {:faker, "~> 0.19.0-alpha.5", only: :test}, which tells you the intended audience is test code rather than production paths. The only: :test option keeps the library out of a release build. Anyone writing ExUnit tests, seeding a development database, or populating a Phoenix app with demo content is in scope. Anyone who needs real data, anonymised production data, or referentially consistent records across tables is not.
What the README actually specifies about the mechanism
The repository material is thin on internals, and that is worth stating plainly. The README shows a module namespace, Faker.Address, with a city/0 function, and the troubleshooting section includes a stack trace pointing at lib/faker/address.ex and a city_count/1 function that receives nil. From that trace you can infer the shape of the design: each data category is its own module, each module reads from a data source keyed by locale, and a call like city/0 resolves the current locale before picking a value. The README does not document the locale configuration key, the full module list, or the randomisation strategy, and it explicitly defers to hexdocs.pm/faker and a separate USAGE.md file for examples. Treat the README as an installation guide, not a reference. The one structural claim it does make is that Faker was designed as a lightweight library that can be easily used with other tools, which is consistent with the absence of a database adapter, a schema layer, or any persistence code in the material.
Getting it into a project: the three steps that matter
Installation is three edits. First, add the dependency to the deps list in mix.exs, with the version and the only: :test scope shown above. Second, run mix deps.get. Third, add Faker.start() to test/test_helper.exs, after ExUnit.start(). That third step is the one people skip, and the failure is not obvious: without the application started, calls into the data modules fail with a FunctionClauseError rather than a clear message about a missing application. The README documents exactly this symptom, showing Faker.Address.city_count/1 being called with nil from lib/faker/address.ex:48. Its prescribed fix is to add :faker to the applications function in the mix file. If you are on an older Mix configuration that still uses the applications list, that is the second place the library has to be registered, and it is separate from the deps entry. The stated requirements are OTP 19+ and Elixir 1.6+, which is a low floor and unlikely to block a current project.
The failure mode the README documents, and the one it does not
The documented failure is the FunctionClauseError above, and its cause is a lifecycle problem rather than a data problem: the application was not started, so the locale lookup returns nil and the clause match fails. The README's fix works, but the error message sends you looking at address generation code when the real issue is application startup. The undocumented failure is subtler. Because generated values come from locale data that ships with the library, upgrading Faker can change which values a given call returns, and any test that asserts on a specific generated string is coupled to the library's data files. The README says nothing about seeding the random number generator, so if you need reproducible sequences across runs you should check the hexdocs before assuming it is supported. There is also a scope limit worth naming: Faker generates values, not relationships. If two generated records need to reference each other, or if a generated email has to match a generated username, that consistency is your code's responsibility, not the library's.
Blacksmith and the template approach
The README points to Blacksmith for templating, describing it as a way to build templates for testing purposes, and directs readers to the Blacksmith README for details. The difference in approach is worth spelling out. Faker is a value generator: you call Faker.Address.city/0 wherever you need a city, and the call site decides how the value is used. Blacksmith is a template layer: you define a template for an entity once, and the template describes how that entity's fields are produced. If your test suite creates the same kind of record in a dozen places, the template approach centralises the definition and Faker does not attempt that. If you only need a string in one assertion, pulling in a templating layer is overhead. The README frames Faker's lightness as a deliberate choice so it composes with tools like Blacksmith rather than replacing them, which is the honest way to read the relationship: they operate at different levels.
Maintenance, versioning, and the MIT licence
The dependency as written pins to a pre-release line, ~> 0.19.0-alpha.5, which permits 0.19.x releases but not 0.20.0. That is a conservative constraint for a library whose data files change between versions, and it means upgrading is a deliberate act rather than something that happens on the next mix deps.get. The release history in the material shows v0.19.0, v0.19.0-alpha.4, and v0.19.0-alpha.5 clustered within about a month, plus a later alpha.5 tag, which suggests the project iterates in small increments and does not treat alphas as unusual. If you pin to an alpha, expect to move off it when the stable release lands. The licence is MIT, which permits commercial and closed-source use and requires only that the copyright notice and permission notice be preserved. That is the extent of what the material supports; it is not legal advice, and if licence terms matter to your organisation, read the LICENSE file in the repository rather than this summary. The README also notes that maintainers are elected based on contributions, which is a governance detail rather than a support guarantee: there is no stated support window or backwards-compatibility promise for the data modules.
Who should adopt it and what to check first
Adopt Faker when you want fake values inside Elixir tests without maintaining fixture files, and when you are comfortable treating hexdocs.pm/faker as the real reference because the README is an entry point rather than a manual. The explicit Faker.start() call in test/test_helper.exs is a small piece of ceremony that buys you a library with no runtime dependencies beyond OTP and Elixir. Skip it if your tests assert on exact generated strings and you cannot tolerate the values shifting when the library's locale data changes, or if your records need cross-field consistency that a value generator cannot provide. Before you commit, confirm your toolchain meets OTP 19+ and Elixir 1.6+, add the dependency with only: :test so it never reaches a release, and reproduce the FunctionClauseError path once on purpose so you recognise it when it appears in CI. The library is MIT licensed and small enough to read; the limit is not the licence or the size but the documentation surface, which lives outside the README.
Editorial conclusion
Adopt Faker if you write Elixir tests or seed scripts that need plausible names, addresses, or other fake values without a fixture file, and if you are willing to read hexdocs.pm/faker because the README only points there. Do not adopt it if you need guaranteed deterministic output across library versions, since locale data and generator internals can change between releases. Before committing, verify three things: that your OTP and Elixir versions meet the stated OTP 19+ and Elixir 1.6+ floors, that Faker.start() is in test/test_helper.exs, and that :faker appears in the applications list if you hit the FunctionClauseError the README documents.
Community notes