Too much creativity when picking value-sources

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.

Hi @dvholten

Thank you very much for this in-depth feedback - as you have seen Cover doesn’t currently provide any xml inputs itself. However, this is a feature that we agree would be useful for many users. I have passed your feedback on to the product team for consideration for the future.

Thank you again for your valuable input!

Best regards,

Jane @ Diffblue