Hi all, I suspect that most of us who do test-driven development will probably argue that tests do not slow down our development or, better still, will speed up our development. Usually I find this is true for myself, but not now. I could really use feedback on http://perlmonks.org/index.pl?node_id=503758. In short, I need to use a different strategy to get around the problems outlined in that node (reproduced below).
Cheers, Ovid -- One of the less appreciated benefits of test suites is how they speed up development. It seems counter-intuitive as you're writing twice the amount of code, but the experience of many programmers has been that test suites lead to better interfaces, less time spent tracking down bugs and, due to easier refactoring, a smaller code base that's easier to work with. I personally find that I'm getting much more work done now that I write solid test suites. Until now. 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. -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
