in reply to When Test Suites Attack

This is because XML and XHTML are just text. I need to see the output. I've been finding more and more that small changes in my code are making huge changes in the output and trying to continuously update the tests to exactly match the XML, XSLT and XHTML using Test::XML and XML::XPath has led to a serious productivity drop.

I don't know if this maps to your problem domain - but I was having similar problems with some munging of CSVs that I was doing recently. The flash of the blindingly obvious that I finally got was that I needed to test on a smaller scale.

So rather that doing the moral equivalent of:

eq_or_diff( $input, munge( $input ), 'remap actions, dates and ids');

I moved to:

is( munged_date($start_date , $date) ); # ... more date tests is( munged_action($start_action, $action )); # ... more action tests is( munged_id($start_id, $id )); # ... more id tests

with the eq_or_diff relegated off to the acceptance tests.

This enabled me to progress much faster since I could test the individual tweaks of the data munging bit in isolation.

I'm considering just using Test::WWW::Mechanize to do integration testing through a Web server I run in the tests. This will be much faster and allow me to get my development speed back up. However, I'd be skipping the unit testing of the output. I'll catch the bugs but it will likely take me longer to track them down.

Surely you can get your XML out without having to run a W3 server as well (he asks curiously :-) ?