My question has to do with testing redundancy. If you have a good set of functional tests, is it necessary to write unit tests? Why bother writing unit tests if you have a strong set of functional tests? Are unit tests just a waste of time if they are not checking the final output of a program rather than intermediate operations?

I'm the only one working on a large project which has essentially no tests for any of the code. In an ideal world, I'd have both unit tests and functional tests, and I'd have written the unit tests before I wrote any code and wouldn't be asking this question. But I didn't. And now I have limited time to work on the project.

My desire for testing has led me to stop development until I have a robust set of tests that cover most of the code. I've set to working methodically through each of the scripts with WWW::Mechanize to set up functional tests for each use of each script. I figure functional tests should expose anything that unit tests would show, and by skipping unit testing, I save myself hours of writing tests that are just redundant. Am I wrong in my assumption?


In reply to Functional and Unit Test Redundancy by saintbrie

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":