Fortunately for all of us, Perl makes it very easy to write tests.
Yes, but that's not the whole story. I write tests for my code. And at $WORK, I can even make time to write tests. And while writing code to do a test is usually easy, I still find it takes a long time to create tests. It's not the test itself, which is just calling the code. It's coming up with good test data which on the one side tests all the aspects of the new code, and on the other side can be run without taking too many resources. Tests that take an hour too finish, or will bring the test server to its knees loading the test set are out the question. So are test sets consisting of one row tables.
But while I do write tests at work (and current project even allocates time for it), not everyone of the business is convinces this is right. This frustrates some of my coworkers. It doesn't frustrate me - I can see the POV of the business. If I spend XX hours a year writing tests, I cannot spend the XX hours writing other tools that help streamlining the work of other departments. So, the company invests XX development hours in getting tests. But I cannot quantify what the company gets back (yes, I can *describe* what they get back, but I cannot put a value on it). Sure, if there are tests, it's (hopefully) easier to change the code, or at least, prevent breaking it. But in our company, code "lives" an average of about 2.5 years - after that, code is obsolete, rewritten or replaced, so tests only have a limited shelf life. I can say the quality of what I deliver increases if I have tests for it. I cannot say the *value* of "XX hours of writing code + YY hours hours of writing tests" is more than "(XX + YY) hours of writing code". And a better value for the company means the company makes more profit. And if the company makes more profit, I get a bigger bonus (bonusses at $WORK are strongly correlated to profit $WORK makes).
