Some days you may be the best XSLT exponent on the planet; other days you may make a simple mistake and not realise it.
Particularly when you are writing tests after someone else wrote the stylesheet, if you find yourself on a roll with all your new tests coming up green first time, it can be useful to occasionally break a working test a little so that it’s bound to fail. If the test fails, then you’ve confirmed what you already knew, and you can fix the test and move on.Â If the test doesn’t fail, that’s useful information, too, since you’ve shown there’s a mistake in the tests or the stylesheet.
It doesn’t really matter how you break the test, provided that it really is broken and that you can change it back easily.Â Little ways of breaking a test include: adding a character to element or attribute names, either in XPaths in assertions or in expected results; deleting an element or attribute in expected results; or adding a character or two to expected text or attribute values.
I recently added tests to a stylesheet and tests written by a client.Â I did purposely break a working test from time-to-time to check that things were as I expected (and from time-to-time accidentally break a test on the way to getting a working test).Â However, a few of the tests that I’d received were written with assertions that would never fail, and these had to be rewritten.Â Happily, the section of the stylesheet that they covered was correct, which goes to show that some days you may be the best XSLT exponent on the planet and other days you may make a simple mistake and not realise it.