The reason why I have not blogged in more than two weeks, was that I was hoping to blog about the CDK 1.2.0 release. This was originally aimed at\nSeptember, slipped into October, November and then December. There were only three show stoppers (see this wiki page),\none of which the IChemObject\ninterfaces were not properly tested.
\n\nThe problem was that the unit tests for the methods in superinterfaces were not applied to implementations of subinterfaces.\nFor example, the unit test for IElement.getSymbol() was not applied to the class Atom, which implements IAtom which\nis a subinterfaces of IElement.
In fixing this, I had to take some hurdles. For example: the unit test classes used a set up following the implementations; CDK 1.2.x has three\nimplementations of the interfaces: data, datadebug and nonotify. The last does not send around update notifications, and rough tests indicate it\nis about 10% faster. The second implementation sends messages to the debugger for every modification of the data classes, which is, clearly,\nuseful for debugging purposes.
\n\nHowever, the JUnit4 test classes were basically doing the same. The unit test DebugAtomTest inherited form AtomTest, and only overwrote\ncustomizations. AtomTest, itself, inherited from ElementTest. That’s where things got broken. In the single implementation set up, this\nwould have been fine, but to allow testing of all three implementations, getBuilder() had to be used.
And when I implemented that, I did not realize that ElementTest would do a test like:
IElement element = builder.newElement();\n// test IElement functionality\nHowever, while the use of builder ensure testing of all three implementations, it does not run these tests on IAtom implementations.
The followed a long series of patches to get this fixed. One major first patch, was to define unit test frameworks like AbstractElementTest\nwhich formalized running unit tests on any implementation, as I noticed that quite a few tests were still testing one particular implementation.\nThis allowed DebugElementTest to extend AbstractElementTest, instead of ElementTest, which would now extend AbstractElementTest too.
OK, with that out of the way, it was time to fix running the unit test for IElement.getSymbol() on IAtom.getSymbol(), which required the\nremoval of the use of IChemObjectBuilder implementations. So, I introduced newChemObject() which would return a fresh instance of the\nactually tested implementation. That is, DebugAtomTest would return a new DebugAtom, and the getSymbol() test would now run on\nDebugAtom and not DebugElement. Good.
No, not good. The actual implementation I was using, looks like:
\n\npublic class DebugElementTest extend AbstractElementTest {\n @BeforeClass public static void setup() {\n setChemObject(new DebugElement());\n }\n}\n\npublic abstract class AbstractElementTest extend AbstractChemObjectTest {\n @Test public void testGetSymbol() {\n IElement element = (IElement)newChemObject();\n // do testing\n }\n}\n\npublic abstract class AbstractChemObjectTest {\n private IChemObject testedObject;\n public static setChemObject(IChemObject object) {\n this.testedObject = object;\n }\n public IChemObject setChemObject(IChemObject object) {\n return (IChemObject)testedObject.clone();\n } // just imagine it has try/catch here too\n\n // and here the tests for the IChemObject API\n @Test public void testGetProperties() {\n IChemObject element = (IChemObject)newChemObject();\n // do testing\n }\n}\nExcellent! No.
\n\nWell, yes. The above system works, but made many unit tests fail, because of bugs in clone() methods. The full scope has to be explored,\nbut at least IPolymer.clone() is not doing what I would expect it to do. Either I am wrong, and need to overwrite the clone unit tests\nof superinterfaces in AbstractPolymerTest, or the implementations needs fixing. I emailed the cdk-devel mailing list and filed a bug\nreport. But having about 1000 unit tests fail, because of clone broken, is something I did not like. For example, as it makes bug fixing\nmore difficult.
So, next step was to find an approach that did not require clone, but give some interesting insights in the Java language. JUnit4 requires\nthe @BeforeClass method to be static. This means I cannot have a non-static DebugElementTest method return an instance. And, you\ncannot overwrite a static method! That had never occured to me in the past. DebugElementTest.newChemObject() does not overwrite\nAbstractChemObjectTest.newChemObject which is somewhere upstream.
But, after discussing matters with Carl, I ended up with this approach:
\n\npublic abstract class AbstractChemObjectTest extends CDKTestCase {\n private static ITestObjectBuilder builder;\n public static void setTestObjectBuilder(ITestObjectBuilder builder) {\n AbstractChemObjectTest.builder = builder;\n }\n public static IChemObject newChemObject() {\n return AbstractChemObjectTest.builder.newTestObject();\n }\n}\n\npublic interface ITestObjectBuilder {\n public IChemObject newTestObject();\n}\n\npublic class DebugAtomTest extends AbstractAtomTest {\n @BeforeClass public static void setUp() {\n setTestObjectBuilder(new ITestObjectBuilder() {\n public IChemObject newTestObject() {\n return new DebugAtom();\n }\n });\n }\n}\n