Database
Goose is the most widely-used database migration tool in the Go ecosystem, but its simplicity makes it easy to ship migrations without testing them. This guide covers a complete testing strategy using testcontainers-go, Go's standard testing package, up/down migration verification, and SQL assertion patterns that integrate naturally
Database
Alembic is the standard database migration tool for SQLAlchemy applications, but its revision system is easy to break silently. This post covers a complete pytest-based testing strategy: upgrade and downgrade testing with real databases, Testcontainers for isolated environments, SQLAlchemy fixture patterns, and idempotency verification to catch the errors that only
Database
Atlas brings declarative schema management to database migrations, letting you define what your schema should look like rather than how to get there. This post covers automated schema validation with atlas schema diff, lint-driven migration safety checks, CI/CD pipeline integration, and drift detection to keep your database and codebase
Database
Liquibase changelogs applied without testing are a production incident waiting to happen. This post covers every layer of the Liquibase testing stack: updateSQL dry-runs, Testcontainers-backed integration tests, rollback verification, and precondition testing to guard against environmental assumptions. Key Takeaways Dry-run before you apply. liquibase updateSQL generates the SQL that would
Database
Supabase testing starts with supabase start for a fully local Postgres stack, pgTAP for Row Level Security policy validation, and Deno's built-in test runner for Edge Functions — all running locally without any remote API calls. Key Takeaways RLS policies are database logic — test them in the database. pgTAP
Database
PlanetScale's database branching model lets you create isolated test databases from production schema in seconds. Pair that with automated schema change validation and Vitess compatibility checks, and you have a testing workflow that catches production incidents before they happen. Key Takeaways Database branches are your test environments. PlanetScale
Database
Neon's branching API makes test isolation cheap — create a branch per PR in seconds, run tests, delete it. But serverless Postgres has specific behaviors around cold starts, connection pooling, and branch state that need explicit testing coverage. Key Takeaways Branches are the unit of test isolation. Neon branches
Database
Flyway migrations can silently corrupt production databases if shipped without proper testing. This post covers a layered testing strategy: unit tests with H2 for fast feedback, Testcontainers for real-database fidelity, rollback testing, checksum validation, and CI pipeline integration. Key Takeaways Test migrations against a real database engine. H2 is fine
Database
Testing Firestore well means combining the Firebase Emulator for integration tests, @firebase/rules-unit-testing for security rule validation, and carefully structured async tests for real-time listeners — all without touching production Firestore. Key Takeaways Security rules are code — test them like code. Every path in your firestore.rules file has a happy
Database
Testing DynamoDB effectively requires a combination of local emulation with LocalStack, fast unit tests with mocked clients, and targeted integration tests that validate single-table designs, GSIs/LSIs, and PartiQL queries — without touching production AWS. Key Takeaways Use LocalStack for integration tests, not the real AWS endpoint. LocalStack emulates DynamoDB locally
Database
CockroachDB's distributed architecture introduces failure modes that standard database tests miss: transaction conflicts requiring retries, serializable isolation violations, and behavior under network partition. Your test suite needs to cover all three to have confidence in production. Key Takeaways Transaction retry logic is not optional in CockroachDB. The database
Testing
Integration tests live and die by their data. A test that creates an order needs a product to exist. That product needs a category. That category has constraints. Building this state in every test is tedious and produces tests that are tightly coupled to unrelated domain objects. Getting it wrong