go-faker/faker generates test data by reflecting over your Go struct

The struct is the schema

The library's tagline is that it will generate fake data based on your struct, and that is genuinely the whole model. There is no fixture file, no seed format, no schema language. You pass an instance of a type to the generator and it fills the fields.

The repository layout reflects that design. The `person.go`, `address.go`, `phone.go`, `internet.go`, `blood.go`, `payment.go`, `price.go`, `datetime.go`, `user_agent.go`, `lorem.go` and `uuid.go` files at the root are the data providers, one per domain, and `faker.go` is the entry point that walks a struct and dispatches to them by field type. `tag_argument_extractor.go` and `template_tag.go` handle the tag parsing, and `random_source.go` is the random number source that the providers draw from.

The `pkg/` directory holds a separate module, and the module path in `go.mod` is versioned.

module github.com/go-faker/faker/v4
go 1.26.0

The v4 suffix matters in practice. The project was previously at a different path, and the README notes that it used to live elsewhere, so an existing project that depends on the older import path has to change its imports rather than bump a version.

The audience is Go developers writing tests, seeds or demos who want a fixture that looks like real data without pasting a hundred lines of literal values into a test file, and who want the fixture to keep compiling when the struct changes. That last property is the real argument for a struct driven generator, since a hand written fixture breaks the moment a field is added and a generator fills it.

Struct tags are the whole configuration surface

The README's example index lists the tag capabilities, and the test files named for each one are the documentation.

The basic tags are covered in `example_with_tags_test.go`, and. Length and bounds are separate, in `example_with_tags_lenbounds_test.go`, and they are what stop a generated string from being three characters long when the database column is sixty. A language tag is handled in `example_with_tags_lang_test.go`, a unique tag in `example_with_tags_unique_test.go`, and a slice length tag in `example_with_tags_slicelength_test.go`.

The template tag is the most interesting of the set, because it derives one field from another. The README lists it as the template tag for derived fields, and the limitation section is precise about what it can do: it currently only supports `string`, named string types and `*string`, and it can only reference the fields of the struct that declares it. So a template can compose a display name from a first and last name field on the same struct, but it cannot reach into a nested struct's field.

The `oneof` tag picks a value from a set, and the README is equally specific that it currently only supports `string`, the int types, and both float types, with wider support described as coming later. It also notes the library does not support private fields at all, and that such fields would trigger a panic, which is the single most common way a first run of this library ends badly.

For fields you want left alone, the skip tag `faker:"-"` omits them, and the README points out that this is the way to handle a private field, since the alternative is a panic.

Custom providers cover the types the library cannot know

Anything outside the built-in type list needs a provider, and the mechanism is documented well enough to be used without reading the source.

The list of supported field types in the README is long and specific: pointer fields of any type, the signed and unsigned integer families, `bool`, `string`, `float32` and `float64`, structs and nested structs, slices and arrays of any type, and maps of any key and value built from supported types.

Beyond that, custom struct types are supported by registering a `StructTypeProvider` and implementing your own generator function, and the README points at an example in `faker_test.go`. It also notes that a default `time.Time` provider is registered and that you can override it by registering your own, which is a useful detail because a `time.Time` field with a fixed random offset in the past is rarely what a test wants.

The limitation section adds the rule for the rest: some extra custom types can be supported if and only if they are extended with `AddProvider()`, and the README points at the custom faker example. So the extension point is not optional decoration, it is the only route for a type the library does not ship, and the cost of forgetting it is a panic or an empty value rather than a compile error.

The README draws the line explicitly for the cases it refuses. It does not support the `any` type, on the grounds that there is no way to generate a value without knowing the type, and the same reasoning rules out `map[any]any`, `map[T]any` and `map[any]T`. The reasoning is sound, but the practical effect is that a struct containing an `any` field cannot be generated at all, which is a constraint on the domain model rather than on the test.

The benchmark the README publishes, and what it means

The README includes a benchmark section, and the numbers are worth reading because they show where the cost of this library sits.

BenchmarkFakerDataNOTTagged-4             500000              3049 ns/op             488 B/op         20 allocs/op

 BenchmarkFakerDataTagged-4                100000             17470 ns/op             380 B/op         26 allocs/op

Generating a struct without tags runs at roughly 3049 nanoseconds per operation, while the same work with tags is reported at 17470 nanoseconds per operation. The tagged path is several times slower, and the memory figures are close, with the tagged variant allocating slightly more but using less total space.

The reason is the tag parsing, which is why the library has a dedicated file for extracting tag arguments. Every field with a tag means reading and interpreting that tag, and the cost is paid on every generation call rather than once.

For the intended use, this rarely matters. A fixture is generated inside a test or a seeding command, and microseconds are irrelevant next to the rest of the test. It becomes relevant in one place, which is a loop that generates thousands of records to seed a database, where the difference between three and seventeen microseconds per record is the difference between a quick seed and a slow one.

The `random_source.go` file is the other half of this story. A library that produces random values by default has to offer a way to make them reproducible, and a dedicated source file is where that lives, so a test that fails on a random value can be reproduced rather than chased.

The Go version floor and the project's own toolchain

The dependency picture is minimal, and that is a point in the library's favour.

go 1.26.0

require golang.org/x/text v0.40.0

One dependency, `golang.org/x/text`, which is what provides the language aware text generation behind the language tag. A test data library that pulls in a framework or an ORM would be unusable in half the projects that need it, so a single dependency is a deliberate constraint rather than an accident.

The Go version floor is the thing to notice. The module declares `go 1.26.0`, and the same number appears in the project requirements section, so the library needs a recent toolchain. Teams pinned to an older release line cannot use the current version, and the fix is a toolchain upgrade rather than a version constraint.

The development toolchain in the repository shows the same seriousness. The `Makefile` exports a local `bin` directory onto the path, uses bash as the shell, and includes a tools makefile from the `misc/` directory. The build target depends on the tests, and the test target runs `gotestsum` and then parses the output with `tparse`.

build: test
	@go build ./...

The test arguments are worth a glance, because they show what the project considers important. The suite runs with `--max-fails 2`, in parallel, with `-test.count 1` so caching never hides a failure, with `-test.failfast`, with a cover profile, a 60 second timeout, and the race detector enabled.

	TESTS_ARGS += -test.parallel 2
	TESTS_ARGS += -test.count    1
	TESTS_ARGS += -test.failfast

The race detector on a library that fills shared structs is a sensible thing to insist on, and the fail-fast setting keeps a broken build from running the whole suite.

Releases every few weeks, and a licence that lets you ship it

The maintenance picture is straightforward and healthy on the evidence available.

The repository is not archived, and the last push was on 2026-10-13. The recent release history shows v4.10.1 on 2026-07-25, v4.11.0 on 2026-08-15 and v4.12.0 on 2026-09-13, which is a cadence of roughly one release a month within the v4 line. The version numbers climb steadily rather than jumping majors, so the module path stays at v4 and the import line in your code does not change.

The licence is MIT, with the text in the `LICENSE` file, so a library used to generate test data or seed data in a commercial product carries no obligations beyond attribution. The topics on the repository place it in the testing library category rather than the data generation one, which matches how it is actually used.

Two limitations are worth carrying into your evaluation, and the README is upfront about both. The first is the private field problem, which is a design decision rather than a bug, since Go cannot set an unexported field through reflection in the normal way, and the workaround is either to export the field or to tag it with the skip marker. The second is the empty interface, which the library refuses to guess at, and the fix there is a provider or a change to the model.

Neither is a reason to reject the library for most projects, and both are reasons to read the limitation section before you write the first fixture rather than after.

Editorial conclusion

go-faker/faker fits Go teams that want fixtures generated from their own types, with tags controlling names, lengths, ranges and uniqueness, and who need a seeded generator for reproducible tests. Skip it if your model has unexported fields you cannot restructure, if you need values for the empty interface or for maps keyed by any, or if you want locale aware data beyond what the language tag covers. Verify first which fields in your structs are exported, register a provider for any custom type before you generate, and pin the module version since the library releases every few weeks.

Frequently asked questions

Official sources

1. go-faker/faker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases