If you have comprehensive tests, you can refactor boldly. This is liberating and makes your code less like to become a superfund site.
Last year I wrote a bunch of SQL handling stuff under the constraint that I couldn't use my beloved DBIx::Class or any other ORM. I wrote tests as I went. Foolishly, at the end of it I discovered that the shop did have SQL::Abstract which is basically what I was rewriting but less well. I switched all the new code to SQL::Abstract inside of an hour. That was easy. The tests showed me several things I'd missed or made bad assumptions about when I refactored. Because of the tests 1) no bugs ever made it to production, 2) a refactor of two weeks worth of code took 2 hours instead of 2 more weeks.
There are other benefits to testing. I do a lot of development on personal projects. Tests allow the quality of things I write to go from "works for me how I use it" to "works for everyone, I'd recommend it."
I am increasingly impressed with Test::Class. Test::More is great but it provides no structure so it's easy to get spaghetti of tests. Keeping your tests easy to manage and fun to work with keeps you and your tests going. I also recommend Perl Testing: A Developer's Notebook, ISBN 9780596100926.
In reply to Re: Testing Perl Code
by Your Mother
in thread Testing Perl Code
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |