How about unit tests using another Derby configuration rather than the localderby configed in entityengine.xml by default? And further, separate the test code and demo data to a new folder, when interface is defined and use cases (demo seeds) are given out, the test case coding can be paralleled to the function coding?
I guess this will make run-test simple and independent. Shi Yusen 在 2008-10-31五的 09:57 +0000，Ray写道： > 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. > > > >
