Pro's and Con's of unit testing after the fact

Question

I have a largish complex app around 27k lines. Its essentially a rule drive multithreaded processing engine, without giving too much away Its been partially tested as it\'s been

Answer 1

If development is "done" I would say that there is not too much point in unit testing.

Answer 2

Unit testing doesn't prove that a system works. It proves that each unit works as an independent unit. It doesn't prove that the integrated system will work

Unit testing "after the fact" is useful for two things - finding bugs that you've missed so far and won't find using any other kind of testing (especially for rare conditions - there's huge numbers of rare conditions that can happen in particular units for any real world system), and as regression tests during maintenance.

Neither of these is going to help much in your situation - you need to do other forms of testing either way. If you don't have time to do what you need to do, taking on even more work is unlikely to help.

That said, without unit testing, I guarantee you will have nasty surprises when the customers start using the code. It's all those rare conditions - there's so many of them that some of them are bound to occur soon. Black-box testers tend to get into habitual patterns, which mean they only test so many rare cases - and they have no way of knowing what rare cases there are in particular units and how to trigger them anyway. More users means more variations in usage patterns.

I'm with those who say unit tests should be written as part of the programming process - one of the programmers responsibilities. As a rule, code gets written faster that way, as you get fewer and less complex bugs to track down as you go, and you tend to find out about them when you're still familiar with the code that has the bug.

Answer 3

I think there are several advantages to unit testing existing code

• Regression management
• Better understanding of the code. Testing it will reveal cases you did not anticipate and will help define the behavior of the code
• It will point out design deficiencies in the code as you stuggle to test poorly defined methods.

But I think it's more interesting to consider the cons of unit testing code. AFAIK, there are no cons. All of the time spent adding tests will pay for themselves even in everything but the shortest of time cycles.

Answer 4

Here's a few of each to my mind:

Pro:

• Time is saved in not having to test methods that have been removed as the design evolved over time. What is left is what really has to get tested.
• By adding tests, this allows an opportunity to review all the aspects in the app and determine what other optimizations one could add now that a working prototype is ready.

Con:

• Large time investment to get the tests written, new functionality may be delayed for some time to generate all the tests.
• Bugs may have been introduced that the tests will discover that may cause this to be longer than initially planned.

The main point would be that adding unit tests allows for refactoring and putting more polish on the application.

Answer 5

Unit testing "after the fact" is still valuable, and provides most of the same advantages of unit testing during development.

That being said, I find it's more work to test after the fact (if you want to get the same level of testing). It's still valuable, and still worth while.

Personally, when trying to tackle something with limited time, I try to focus my testing efforts as much as possible. Any time you fix a bug, add tests to help prevent it in the future. Any time you're going to refactor, try to put enough testing in place to feel confident you're not going to break something.

The only con of adding unit testing is that it does take some development time. Personally, I find that the development time spent on testing is far outweighed by the time saved in maintenance, but this is something you need determine on your own.

Answer 6

If you are doing any refactoring, those tests will help you detect any bugs that will appear in the process.