At first blush this seems like a crazy idea. Surely the whole point of having a test suite is to discover what you're not expecting to happen as a consequence of some change. Tying the tests to a particular known-to-be-OK state of the Guidelines renders the whole exercise pointless. But thinking about it again, I think Martin is actually suggesting a very practical way of improving the workflow in the build. When rebuilding the stylesheets, you need to regenerate the expected-results twice: once using the new p5subset.xml, and once using the old one (tied to the last major release). You then need to compare the two sets of expected-results and take action on any nasties that come creeping out of the woodwork. Repeat until clean. Then (and only then) you can save the new set of expected results ready for next time. On 18/07/2019 02:01, Martin Holmes wrote:
Hi all,
I think there's a possible partial solution to the chaos resulting from the fact that Stylesheets tests depend on p5subset.xml, so whenever the Specs change, the expected-results in the Stylesheets tests may also change.
This is because we always try to use the same p5subset for every test: the current release. But if we make each test point at a specific version of p5subset.xml in the Vault, then that version will never change; so the Stylesheets output should also never change, unless we change the Stylesheets themselves, in which case we want to see what changes in the expected-results anyway.
Anyone see any problem with this?
Cheers, Martin _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council