Open-Source Testing · go-testfixtures

testfixtures

testfixtures is a Go library that loads test data from YAML files into a real database before running tests, mimicking Ruby on Rails' fixture approach. It supports multiple databases (PostgreSQL, MySQL, SQLite, SQL Server) and includes safeguards to prevent accidental data loss on production databases.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/go-testfixtures/testfixtures

1.2k

GitHub stars

Forks

Primary language

MIT

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	go-testfixtures/testfixtures
Owner	go-testfixtures
Primary language	Go
License	MIT — OSI-approved
Stars	1.2k
Forks	91
Open issues	15
Latest release	v3.19.0 (2025-10-25)
Last updated	2026-07-03
Source	https://github.com/go-testfixtures/testfixtures

What testfixtures is

A Go package providing fixture management for database-driven tests via YAML configuration, with automatic type conversions (JSON, timestamps, binary), sequence resets, foreign key handling via database-specific mechanisms (triggers, constraints), and checksum-based optimization to skip redundant reloads.

Quickstart

Get the testfixtures source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/go-testfixtures/testfixtures.git2cd testfixtures3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Web application integration tests

Test HTTP handlers and business logic against a real database schema with known, reproducible data states. Particularly effective for Go web frameworks (Echo, Gin, Chi) where database interactions must be validated end-to-end.

Multi-table relational data testing

Validate complex queries and transactions involving foreign keys, cascading deletes, and data integrity constraints by loading interconnected fixture data across multiple tables in a single operation.

Database migration and schema evolution testing

Ensure backward compatibility and correct behavior when schema changes are applied; load fixtures against different database versions to verify migration scripts work correctly.

Implementation considerations

Create a dedicated test database and verify its name contains 'test' (or explicitly disable the safety check); testfixtures will wipe all data on Load(), so connection validation is critical.
Design YAML fixture files to match table schemas exactly, including foreign key ordering (load parent tables before children to avoid constraint violations).
Use RAW= prefix for database-generated values (UUIDs, timestamps, sequences) and handle dialect-specific syntax (PostGIS, ClickHouse) in fixture definitions.
Configure sequence resets appropriately per database (PostgreSQL/MySQL default: 10000) to avoid primary key collisions across test runs.
Consider disabling checksum computation if test fixtures are large or if Load() is called infrequently, to improve performance.

When to avoid it — and what to weigh

Unit tests requiring mock isolation — If you need fast, isolated unit tests without I/O overhead, mocking is more appropriate than real database fixtures. testfixtures is designed for slower, real-database integration tests.
High-volume stress or performance testing — Fixture loading and cleanup add overhead per test. For load testing or benchmarking where thousands of test iterations are needed, this approach is inefficient.
Tests requiring dynamic fixture generation or parameterization — YAML fixtures are static; if tests need programmatically generated or parameterized data (e.g., varying record counts, random values), you'll need custom setup logic alongside or instead of fixtures.
Environments where database access is restricted or unavailable — CI/CD pipelines without database containers, serverless test environments, or offline development require a working database instance. testfixtures cannot work without it.

License & commercial use

MIT License (OSI-approved, permissive). Allows use in proprietary and open-source projects with minimal restrictions (attribution required, no warranty/liability).

MIT is a permissive OSI-approved license; commercial use (including proprietary/SaaS applications) is explicitly permitted. Include a copy of the MIT license text and copyright notice in your project. No commercial support or SLA is mentioned in the repository.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Strong
Assessment confidence	High

Security considerations

testfixtures includes a safety mechanism: refuses to load fixtures unless the database name contains 'test' (disableable via DangerousSkipTestDatabaseCheck()). This reduces accidental data loss on production databases. However, no mention of SQL injection protections, parameterized query usage, or audit logging. Review source code if fixtures handle untrusted data. Fixture YAML files are static code; ensure they do not expose secrets.

Alternatives to consider

go-sqlc + hand-written test data setup

Type-safe SQL generation without fixtures; more control over test data setup but requires manual database seeding logic per test.

testcontainers-go (Docker-based databases)

Provision isolated test database instances programmatically; pairs well with testfixtures for CI/CD but adds container overhead.

sqlc mock queries + table-driven tests

Mock database layer entirely; faster, no I/O, but does not test real SQL execution or schema evolution.

Software development agency

Build on testfixtures with DEV.co software developers

Our engineers can set up database-driven tests, design fixture schemas, and optimize CI/CD test pipelines. Contact us for a free consultation.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

AutoFixture testcontainers-go gotests

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing API Development Application Development DevOps Talk to DEV.co

testfixtures FAQ

Will testfixtures work with my ORM (gorm, ent, sqlc)?

testfixtures loads data via raw SQL, independent of ORMs. It works alongside ORMs—use it to seed the database, then test your ORM queries against real data.

How do I handle auto-increment/sequence collisions across tests?

testfixtures automatically resets sequences to 10000 (configurable) for PostgreSQL and MySQL/MariaDB. For SQLite and manual cases, use RAW=sqlite_sequence or equivalent; test isolation depends on sequence reset behavior.

Can I use testfixtures with CI/CD without a persistent database?

Yes, but you must provision a test database in your CI pipeline (e.g., Docker service, testcontainers, or managed database). testfixtures requires a live connection at test time.

Does testfixtures support parallel test execution?

Not explicitly documented. Parallel tests sharing a single database and calling Load() concurrently may cause data races or lock contention. Use separate test databases per parallel worker or serialize fixture loads.

Software development & web development with DEV.co

From first prototype to production, DEV.co delivers software development services around tools like testfixtures. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source testing and beyond.

Need help integrating testfixtures into your Go test suite?

Our engineers can set up database-driven tests, design fixture schemas, and optimize CI/CD test pipelines. Contact us for a free consultation.

Talk to DEV.co Schedule a Consultation