the attached test-method is an example of overboarding enthusiasm when generating test-values. The tested class deals with some not too simple, not too complex, schema protected xml-template file, which is filled with some values. Some Document, some Elements, some NodeLists, some NameSpace, nothing special.
I see, that Diffblue wants to play with the UIPidxCompartment and needs some w3c.Document and some w3c.Element to plug into the createReference()-method. However, going through the classpath, finding Apache Batik to get an SVG-Document and asking imageio to get some Element, seems to be a litte bit to creative, imo (btw, the JavaDoc of IIOMetadataNode indicates, that it is not a good general purpose Element).
The second listing shows the consequence of this creativity: Diffblue goes through the API of the SVGDocument and tries to prove things, which are not relevant in the context of UIPidxCompartments.
These tests are rather useless. I delete them and replace them with handmade tests, which try to follow Diffblue’s intent.
Of course I see the problem: where to get some required values? During the initial test-generation? After this, the programmer can provide data in the yaml-file. Then he can re-run the test-generation and see, if it works better. This can be done after one sees the mess with these generated tests.
I propose this: whenever you need some simple, generic XML-thing (document, element, attribute, whatever) provide your own - within the test-method. Using Java15 text-blocks and the JRE-integrated XML-handling it should not be too difficult to provide minimalistic objects, which are just ‘good enough’. Programmer has a nice little template to either extend ‘in situ’ to come closer to his requirements, or he can drop that and use his own specialised object-factories (or yaml-file). Anyway, this initial simple objects are most likely better than something drawn from some random library which happen to know something about XML.
