Test Strategy
Risk-based testing is a prioritization method: test the things that will cause the most damage if they break. It doesn't mean testing less — it means allocating limited testing time toward the highest-impact, highest-probability failure points first. When time runs out before full coverage, you'
Database Testing
Schema drift is one of the most dangerous forms of technical debt in database-driven applications. It happens gradually: a developer adds a column directly to staging but forgets to write a migration, another runs a manual ALTER TABLE on production to fix an emergency, and a third adds an
Testing
You can't test everything. This is not a failure of planning or resources — it's a mathematical fact. A typical web application with a few hundred features and their interactions would take months to test exhaustively. Your release cycle is two weeks. Something has to give. Risk-
Test Automation
Your application code can be perfectly correct, but if the database schema doesn't enforce the invariants you depend on, you have a latent data integrity problem waiting to surface. Unique constraints that weren't added, foreign keys that got dropped for performance reasons, nullable columns that your
Testing
Risk-based testing was developed in an era of waterfall projects with dedicated QA phases. The concepts are sound — test where failure hurts most — but the original tooling (heavyweight FMEA documents, quarterly risk reviews, formal sign-off chains) doesn't map well onto two-week sprints and continuous deployment.
Database
* Rollback scripts are code — they need their own tests, not just "we checked it in staging once" * Flyway Teams has undo migrations; Liquibase has rollback — both must be explicitly tested * Snapshot-based rollback (restore from backup) is different from script-based rollback — test both * Data preservation tests verify
Deployment Testing
Database migration bugs are among the most damaging deployment failures. A bad migration can corrupt data, lock tables during peak traffic, or make rollback impossible. Most teams test their application code thoroughly and test their migrations barely at all. This guide covers how to build database migration testing into your
Testing
Having a risk matrix is step one. The harder problem is translating risk scores into actual test case decisions: which tests to write, which existing tests to keep, which to deprioritize, and how to know when you have enough coverage for a given risk level. This post covers the practical
Database Testing
A bad database migration is one of the worst production incidents you can have. Unlike a bad code deploy, you can't just roll back — the data is already mutated. A migration that drops a column, truncates a table, or corrupts data during a lock-heavy ALTER can take
Test Data
The fixtures-versus-factories debate has been running in test communities for over a decade. It's not really a debate — both approaches have distinct strengths, and the teams that struggle most with test data are the ones who picked one dogmatically without understanding the tradeoffs. This guide breaks
Data Testing
Data warehouses are where your organization's most important decisions get made. Board reports, investor metrics, operational dashboards—they all pull from your warehouse. When the data is wrong, so are the decisions. Data warehouse testing is the discipline that ensures your analytical data is accurate, complete, and reliable.
Clojure
Clojure's web stack — Ring for HTTP abstraction, Compojure for routing — is highly testable because it's built around plain functions and immutable data. A Ring handler is just a function from request map to response map. This means you can test your entire HTTP layer without starting