Ovid wrote: > The code is designed well enough that adding new features is quick and > easy. Unfortunately, whenever I need to change my code I fire up a Web > server and view the results in the browser and then write the tests > after I've written the code (this is closely related to When > test-driven development just won't do). 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'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. >
I feel your pain. The test suite for Handel has xml/tt output tests for its AxKit and Template Toolkit plugins. I've got oodles of template pages using the components whos output I compare to static .out files that contain the expected output. Everytime I write a new plugin, or a new tag in the plugin, I waste tons of time just writing the tests for them. So far, I've been good about writing the tests before I write the code, but it takes forever and I rarely get the tests right the first time. I'm curious to see what comes out of your question. I'm in the same boat. -=Chris
smime.p7s
Description: S/MIME Cryptographic Signature
