David E Jones wrote: > > One way or another we want to avoid dependencies between test cases. In > the case of data it means that no test case should depend on data > changes made in a previous test case. Using demo data isn't the thing > that's bad, it's changing something that another test case might depend on. > > The best way to fix this would be to have each test case clean up after > itself. This could involve saving data before changing it so that we can > change it back... or even better let the database do it since it already > supports that through rolling back a transaction... > > We may need to make some changes so that it is clear that the test > succeeded even though the transaction was rolled back (ie the test > runner needs to rollback the transaction, not the test case code itself). > > Does that sound like a reasonable approach?
Nope. Can't have nested/chained transactions, and this won't help the tests that do funky transaction stuff.
