Test Suite Slowing Down My Development
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/
Re: Test Suite Slowing Down My Development
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
Re: Test Suite Slowing Down My Development
--- Christopher H. Laco [EMAIL PROTECTED] wrote: 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. It might be nice if you posted this comment to http://perlmonks.org/index.pl?node_id=503758 If others can see that this is not an unusual problem it might help. Cheers, Ovid -- 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/
Re: Test Suite Slowing Down My Development
-BEGIN PGP SIGNED MESSAGE- Moin, On Friday 28 October 2005 22:34, Christopher H. Laco wrote: 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. I am somewhat in the same boat with Graph::Easy - the t/ascii.t script tests rendering of graphs in ASCII, ala: [ A ] - [ B ] is transformed into: # echo [Test] - [This] .. [ Now ] | perl examples/as_ascii +--+ +--+ +-+ | Test | -- | This | .. | Now | +--+ +--+ +-+ While this works mostly fine for ASCII, the HTML/SVG is undertested because the text/code output can change quite radically, while still rendering/representing the same graph. And of course I do want to test that the end result is the right one, not that the generated SVG/HTML code is a specific example. So everytime I change the HTML template/output, I need to fiddle back a host of tests... Best wishes, Tels - -- Signed on Fri Oct 28 23:33:31 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Ok, a shiny copper piece to the first person who can tell me why Elan is running around naked. - Giant moth attack? - Maybe a bad guy casted 'Dispel clothes'? - The Order of the Stick issue #26 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ2KZ9ncLPEOTuEwVAQEZxAf/Rz/gxvA3w2bbD7D1CfT2HaFe+glj37kT WkJUQ7pj9bEZA/o74WJwpdZyL7MfTe3K6MhqohstrNDL9XxvN0C0ScSQiHlagHny zVl6gdZ9DDhxWBOzHZc5oEdrsV6qhkHkdvusADC3mTb0UZEqgE50RbgERw1Wlu1v 08O5NWmqJTI+KDujqdY5FZ6pBSGUR72eiaWw8UxN7HkSi42DP8/dmnw+23FsVTmc z3sJhNuhaNsVorMHdPHxUs9n5WuXRP/h1cemrrzpx2o3SfP4DBiDoxt0GKMdeRiB s29F8bWWQ4CLUsQqAgk9L4P7fOp00+tqDBLr/9t/ECLiVxWDFTxcWg== =b8rX -END PGP SIGNATURE-
