Good article. Data & state are hugely important for testing, and it's good to see others engaging with the reality of these. I had key responsibility for a ver

Good article. Data & state are hugely important for testing, and it's good to see others engaging with the reality of these. I had key responsibility for a very large software system (10M LOC) which was highly configurable; everything was data-dependent, both for product configuration and the actual accounts being tested. Others had tried building test datasets using in-memory DBs, but the cost of maintaining these test datasets had already exceeded their value without even achieving 10% test coverage. Rather than avoiding the database we took the architectural choice to acknowledge it, leverage the already-available standard configuration datasets, manage & minimize the degree of changes committed (test in transactions & rollback wherever possible), and manage & minimize dependence on pre-existing account state. Within six months we were able to achieve a level of coverage & reliability where >60% of bugs were detected promptly on being introduced. Prior to this they had taken 3-5 days before end-to-end testing had confirmed detection. Use of a database in testing is not completely easy, but sometimes it can be the most efficient solution to the problem at hand.