I made a racket about this: Test Data Management - Prod Data vs Test Isolation | Racket
Using:
- Test isolation
- Gold Copies
- No copy from prod
Some copy pasta notes I had:
Gold Copy Data
What is a Gold Copy Data?
In essence, a gold copy is a set of test data. Nothing more, nothing less. What sets it apart from other sets of test data is the way you use and guard it.
- You only change a gold copy when you need to add or remove test cases.
- You use a gold copy to set up the initial state of a test environment.
- All automated and manual tests work on copies of the gold copy.
A gold copy also functions as the gold standard for all your tests and for everybody testing your application. It contains the data for all the test cases that you need to cover all the features of your product. It may not start out as comprehensive, but thatās the goal.
Managing the Coupling between Tests and Data
When it comes to test data, it is important that each individual test in a test suite has some state on which it can depend.
Only when the starting state is known can you compare it against the state after the test has finished, and thus verify the behavior under test. This is simple for a single test, but requires some thought to achieve for suites of tests, particularly for tests that rely upon a database. Broadly, there are three approaches to managing state for tests.
- Test isolation: Organize tests so that each testās data is only visible to that test.
- Adaptive tests: Each test is designed to evaluate its data environment and adapt its behavior to suit the data it sees.
- Test sequencing: Tests are designed to run in a known sequence, each depending, for inputs, on the outputs of its predecessors.
Test isolation
Test isolation is a strategy for ensuring that each individual test is atomic. That is, it should not depend on the outcome of other tests to establish its state, and other tests should not affect its success or failure in any way. This level of isolation is relatively simple to achieve for commit tests, even those that test the persistence of data in a database. The simplest approach is to ensure that, at the conclusion of the test, you always return the data in the database to the state it was in before the test was run.
A second approach to test isolation is to perform some kind of functional partitioning of the data. This is an effective strategy for both commit and acceptance tests. For tests that need to modify the state of the system as an outcome, make the principal entities that you create in your tests follow some test-specific naming convention, so that each test will only look for and see data that was created specifically for it.
Notes
Iāll send you my full notes on Test Data Management, itās quite long XD