>Joseph has already answered that, XalanJ project CI configuration for these tests, is still premature to create, and I do agree with him
If the changes are released, then, it is too late to test. It would be better to add CI and test the changes **before** releasing the changes. CI could help track code coverage, so everybody knows if there is untested code. >If you're really interested to review these XSLT transformation tests that I've provided, then test names like test1, test2 ... shouldn't matter. Selecting method names, variable names, and class names helps readers to understand the intention behind the code. Of course, everybody can reverse-engineer the intention from analyzing the XML contents. However, the code with "test1, test2, tets3" methods takes more time to understand than a code with reasonable names. >I believe that, this pattern to run all the tests available within a file like "AnalyzeStringTests" There are ways to extract common code. For instance, have you considered adding a method like the following? I just copy-pasted the code from https://github.com/apache/xalan-java/blob/c540addb5d3da6f66be9e5746c1d4516199f0c20/tests/org/apache/xalan/xpath3/FnStringJoinTests.java#L84-L97 However, I believe it is pretty-much the same all over the place. There are common error patterns in the code: a) use of default encoding in new String(byte[]) b) Assert.fail() would swallow exception, and it would make it hard to understand the failure Factoring common code helps to prevent copy-pasting the same errors into many classes. public static void runTransformAndAssertOutput(File xmlFilePath, File xlsFilePath, File goldFilePath) { try { Node xmlDomSource = docBuilder.parse(new InputSource(xmlFilePath)); Transformer xslTransformer = tfactory.newTransformer(new StreamSource(xslFilePath)); StringWriter resultStrWriter = new StringWriter(); xslTransformer.transform(new DOMSource(xmlDomSource), new StreamResult(resultStrWriter)); byte[] goldFileBytes = Files.readAllBytes(Paths.get(goldFilePath)); Assert.assertEquals(new String(goldFileBytes), resultStrWriter.toString()); } catch (Exception ex) { Assert.fail(); } } An alternative option could be using https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests Yet another alternative would be https://approvaltests.com/ Frankly speaking, it is inconvenient to comment on code change in email, and it would be way easier to review code if you could create a PR with the changes. Do you think you could create PRs? Vladimir
