Daniel John Debrunner wrote: >Daniel John Debrunner wrote: > > > >>David W. Van Couvering wrote: >> >> >> >> >>>I agree with you that is disconcerting, but can't JUnit tests be written >>>that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest >>>cleaned up to everyone's satisfaction? >>> >>> >>Depends, at some point you put the potential burden of fixing all those >>new tests on the person doing the cleanup, that should have been part of >>the original submission. >> >> > >The other issue is that we have a great opportunity to start out with >JUnit tests that follow a consistent pattern and provide a great example >for others to follow. If we add a number of tests now that haphazardly >use the methods in DerbyJUnitTest (because they are not well commented) >then we have a set of tests like the current ones. No pattern, no >obvious starting point leading to people inventing their own ways to get >connections, run ddl, handle exceptions etc. > > > One thing that would be great is if there was a well defined way to have tests handle jvm specific, framework specific or version specific logic, since there will have to be some replacement for the many properties in the test harness and the individual test checks for framework that we have now.
I suggested something like this for the client/server compatibility testing, but did not consider JUnit. It would be good to have something laid out for JUnit testing so that tests are checking whether functionality is suppported and the details of whether that is because of the framework, jvm or whatever are not spread around all the tests. http://www.nabble.com/Server-and-client-compatibility-test-for-10.2-and-10.1-t913020.html#a2499854 Kathey
