elixirs/faker: fake data generation for Elixir test suites

What elixirs/faker actually generates, and for whom

This is a pure Elixir library for producing fake data. The README states that plainly and stops there, which is the right level of ambition for the problem: test suites and seed scripts need plausible values that are not copies of production records. A user record with a name, a street address and a city makes a test readable; a record with "test1", "test2", "test3" does not, and a record copied from production carries data you should not be shipping into a development database.

The intended audience is Elixir developers, most visibly those working in Phoenix projects, judging by the topics attached to the repository (phoenix, seeding, testing, qa). The library is deliberately small. The README says it "was designed as a lightweight library, that's why it can be easily used with other tools", and points at Blacksmith for template-based fixtures. That sentence is also a boundary: Faker supplies values, it does not supply a fixture framework, a database seeder, or a schema-aware record builder. If you want declarative templates, you are expected to reach for something else alongside it.

One consequence of the scope is that the README is thin on the generator API itself. It links to the Hex docs and to a separate USAGE.md file in the repository. Anyone evaluating the library should read USAGE.md rather than the README, because the README documents installation, requirements and a single error case, not the list of available generators.

How the library is structured and when it initialises

The repository layout is a standard Mix project: lib/ for the implementation, test/ for the suite, mix.exs and mix.lock for the build, plus .formatter.exs, .credo.exs and a .tool-versions file. There is no runtime service, no external data file to download, and no network call at generation time. The values come from data compiled into the library, which is what "pure Elixir" means here.

The lifecycle detail that matters is startup. Faker is an OTP application, and the README's troubleshooting section shows what happens when it has not been started: calling Faker.Address.city/0 raises a FunctionClauseError inside Faker.Address.city_count/1, with a nil argument. That stack trace is the signature of a locale or configuration lookup returning nothing because the application is not running. The fix the README gives is to add :faker to the applications list in your mix file, or to call Faker.start() in test_helper.exs. In a normal test setup the second option is the one the Quickstart uses.

That design has a practical implication for anything outside ExUnit. A release task, a seeding script run with mix run, or an IEx session will not have the application started automatically in the same way the test helper arranges it. If you see the FunctionClauseError in a context that is not a test, the cause is almost certainly the same: the application was never started. The README documents the symptom and the fix but does not enumerate every context in which it appears.

Installing Faker and generating your first fake address

The README's Quickstart has three steps. First, add the dependency to mix.exs. The example marks it as test-only, which keeps the library out of production releases:

defp deps do
  [
    {:faker, "~> 0.19.0-alpha.5", only: :test}
  ]
end

Second, fetch it:

mix deps.get

Third, start the application from test/test_helper.exs, after the ExUnit line:

ExUnit.start()
Faker.start()

At that point Faker.Address.city/0 and the other generators are callable from your tests without the FunctionClauseError described in the troubleshooting section. The project requires OTP 19+ and Elixir 1.6+, per the README's Requirements section, so the version constraint in the snippet above is what to check against your own toolchain before you run mix deps.get.

The README does not walk through an example of calling a generator, and it does not list the available modules. For a first real use, the honest instruction is to open USAGE.md or the Hex docs and pick a generator from there, then call it inside a test. The three steps above are the whole of the documented setup; anything beyond them is inference from the library's structure rather than something the README states.

Where Faker is the wrong tool

The most common mismatch is the runtime itself. Faker is an Elixir library, and the installation path is Mix plus Hex. If your tests are written in Python, JavaScript or another language, nothing here applies, and the search results that point at Python or Playwright packages are pointing at different projects that happen to share the name.

The second mismatch is determinism. Faker generates values; it does not replay a fixed dataset. If a test asserts against a specific row, or if a bug report needs to be reproducible from a seed, generated data is the wrong input. The README does not document a seeding or replay mechanism for the generated values, so a team that needs byte-identical fixtures across runs should not assume one exists.

The third is scope. Faker is not a database seeder. It produces values you can insert, but the insertion, the associations between records, and the cleanup between runs are your problem or your fixture library's problem. The README explicitly places templating in Blacksmith's territory, which is a fair signal that the maintainers do not intend to grow Faker into a fixture framework. Treating it as one leads to a lot of glue code.

Finally, the current release line is worth noting. The most recent release listed is v0.19.0-alpha.5 from 2026-07-22, with a stable v0.19.0 from 2026-06-28 before it. The README's own install snippet pins the alpha, which is unusual for a library used in test suites and is something to weigh if your organisation avoids pre-release dependencies.

Faker against Blacksmith: values versus templates

The README names Blacksmith directly as the tool for building templates, and the difference in approach is real. Faker answers the question "give me a city name" one call at a time. Blacksmith, as the README frames it, is for templates: you describe the shape of a record once and reuse it. If your test suite creates the same user with the same fields in a dozen places, a template removes that duplication in a way that calling Faker.Address.city/0 repeatedly does not.

The two are not in competition. The README's phrasing, that Faker "can be easily used with other tools", describes the intended arrangement: Faker supplies the values, a template layer supplies the structure. Choosing between them only makes sense if you are deciding where to spend effort. A small suite with a handful of factories gets little from a template layer and can call Faker directly. A large suite with repeated record shapes will end up writing its own template helper if it does not adopt one, and that helper is the thing Blacksmith already is.

What Faker offers in exchange for the narrower scope is a smaller dependency surface: pure Elixir, no runtime services, and a test-only installation that does not ship in releases. For teams that want exactly that and nothing more, the trade is reasonable.

Licence, maintenance and the cost of upgrading

Faker is released under the MIT License, per the README's License section and the LICENSE file at the repository root. MIT is permissive: it allows use, modification and redistribution with the licence text retained. That is a description of the licence, not legal advice; if your organisation has specific obligations around attribution in distributed artefacts, have someone who can give that advice read the LICENSE file.

On maintenance, the repository is not archived, and the last push was on 2026-09-10. Releases are automated: package.json lists semantic-release together with @semantic-release/changelog, @semantic-release/git, @semantic-release/github and conventional-changelog-conventionalcommits, and the repository carries a .releaserc.json. Commits are analysed for conventional commit prefixes and version numbers and the changelog are produced from that. In practice this means upgrade notes come from CHANGELOG.md rather than from hand-written release announcements, and a breaking change will appear there under whatever heading the commit convention produced.

Upgrade cost itself is low by construction. The dependency is compile-time only, there is no service to migrate and no schema to change. The realistic work is version-constraint maintenance: the README pins an alpha version in its example, and moving off that to the stable line is a one-line edit in mix.exs followed by mix deps.get. The README does not document a rollback procedure for a dependency upgrade, which for a library of this kind is not surprising, but it does mean the rollback is whatever your version control does with mix.lock.

Editorial conclusion

Adopt elixirs/faker if your project is Elixir and you need fake names, addresses and similar values inside ExUnit tests; the dependency is MIT licensed and the README shows a test-only setup that keeps it out of production builds. Do not adopt it if you are working in Python, JavaScript or another runtime, or if you need deterministic fixtures tied to specific records, since the library generates values rather than replaying a fixed dataset. Before wiring it in, check the version constraint against Hex, confirm that Faker.start() has been added to test/test_helper.exs, and read USAGE.md because the README documents almost none of the generator functions.

Frequently asked questions

Official sources

1. elixirs/faker on GitHub
2. Issues
3. License: MIT
4. README
5. Releases