It sounds like you may be committing to writing tests while you are still playtesting your solution and specifications. If you're hacking on the output to figure out what you want, and only know if you've found it through visual inspection, then maybe you need an easy way of capturing/saving the output as the specification because that really is the spec. You can bootstrap it by writing your output directly and then tweak and enhance.

The other thing that occurs to me is that it your tests may be too tightly coupled and you may want to break them down to greater granularity for unit testing. (I.e. just like testing subroutines rather than a whole program.) If you have a template and pass a bunch of stuff to it, write the test for how you want the data structure to be and test that. Then test the XSLT transformations separately. Do you really need to test it end to end on a piece of data?

Put differently, how much does the success of one test depend on the success of the other? Are you re-writing so much of your tests with each change because the tests aren't sufficiently independent? (Some additional discussion on independence, redundancy, and coupling is in Functional and Unit Test Redundancy)