Kathey Marsden wrote: > Rick Hillegas wrote: > > >> >>What if the metadata test internally verified that the version numbers >>from the client driver agreed with the values in dnc.properties? Then >>we wouldn't have to hard code version numbers anywhere: not in the >>test code and not in the canons. We could remove the metadata canons >>from the list in the bumplastdigit target. >> > > I think some centralized location is good but I think dnc.properties is > maybe not quite right because: > > 1) It would be pulling the version right out of the jar being tested so > I think that if we did this and plopped down a 10.1 derbyclient.jar, > the test would pass with a 10.2 derbyTesting.jar. > 2) The test would fail when testing the embedded driver without > derbyclient.jar. > 3) When testing the jcc driver, you couldn't really get a version for > getDatabaseProductVersion() because there is no dnc.properties available.
-1 on the patch of getting the version number from dnc.properties for the reasons laid out by Kathey. I think the previous way is preferred as at least there is a chance to review the version change, since the master file changes. Some visible way to see the version number is good. One of my paranoid fears about the junit assert testing is that it's impossible to tell if a test ran and did everything, or didn't do anything. The output is the same in both cases. Dan.
