Seems OK for the simpler unit tests but would also be good to have a solution that keeps it easy to write higher level tests.
For example small unit tests to ensure stock management in the facility manager works could be quite simple and are essential first level unit tests. But we really need to also write test cases that create customer orders and purchase orders and process those whilst also cancelling orders and order line items and testing that stock levels still work. May not be unit tests exactly but still good to have a data solution that allows them to be catered for, could a rollback really handle that sort of test? Would it be to difficult to write a routine that went through the database and removed all data and then reimported seed/demo? Don't suppose Derby supports checkpoints! Ray 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? > > -David > > > On Oct 30, 2008, at 11:39 PM, Adam Heath wrote: > >> Scott Gray wrote: >>> I'm talking about demo data not seed data, I don't see why the demo >>> data can't be used for testing? >> >> That is exactly the problem. Testing mutates things. If each test has >> it's very own set of data, then there will never be a clash with >> anything else. >> >> And, the demo data is useful for those wanting to see how various parts >> of ofbiz function, OOTB. >> >> Reusing them can only lead to headaches, which is why we have the full >> test suite containing so many failures. > >
