Writing Unit Tests in the Middle

Question

Is unit testing a 100% or not at all kind of deal?

I was browsing through my old projects and started adding features, this time with unit testing. However, is this ultimately worthless if I'm going to be re-using past components that do not have unit tests?

Do I need to write unit tests for all the previous classes and not bother at all, or is it OK to only write unit tests for the new stuff I'm adding?

Answer 1

Any unit tests are better than none. So it's not an all-or-nothing deal.

In your case, since Test Driven Development has not been the norm - you'll wonder how the tests are of any use.

You want to ensure that any future code you write doesnt break any (current) functionality - and that's where your sub-cases come in handy. If the well-written tests pass, you most likely have not damaged anything. The next developer who comes along will thank you for the tests and documentation.

What you can start with is if you have a well split up layered architecture, pick up the data access tiers and work upwards (towards UI tier) with the tests. If the project has a domain model its the most likely candidate for TDD as its likely to have most of the logic. If the service (or business logic) tier is just making a call to Domain/Data Access tier no point in doing Service tier in TDD fashion. Those are fluffy tests and not of much value.

Added to a code coverage tool like Emma - and you can steadily monitor the improvement in overall test coverage.

Answer 2

I have worked on a very large code base which initially had no unit tests. By following a few practices we now (after several years) have most of the code base covered by tests.

All new code must have unit tests.

All changed code must have unit tests added to it.

The way that we safely added tests to old code without breaking it is primarily to use the following basic approach:

Choose a small section of code that you need to change the functionality of.

1. Try to create system level integration tests to surround the code. Because of the combinatorial complexity of testing at this level, these tests will only form a "smoke" test to pick up major mistakes.

2. Introduce the interfaces you need in order to be able to test the code you are changing. Use Refactoring techniques consisting of sequences of very small changes which you have high confidence are correct. Try to use tool support where possible. You might do this by, for example, moving/extracting the method you are changing onto its own object. Check in your changes regularly so you can revert. Regularly peer-review how you made the changes by going through the revision control history.

   Try to make the minimum about of changes that are required in order to break the dependancies that are preventing you from adding tests.

3. Write tests to as far as possible cover the functionality of the code that you are going to change. Check in regularly and peer review all changes.
4. Write tests for the new functionality/functionality change.
5. Implement the functionality (this is your normal TDD cycle)
6. Make sure to refactor the areas you have covered by the tests (red-green-refactor).

We found that the more we did this, the easier it got. As every time you go back to the code base, it is a little bit better.

We have seen a massive drop in the number of bugs getting through to our QA testers. With functionality regressions being now almost unheard of, so I think it was worth the effort for us.

Answer 3

Is unit testing a 100% or not at all kind of deal?

Absolutely not! Start testing the new code you are adding. You will see immense benefits from doing that, even if some of the older components don't have tests. As you have to deal with one of those components, or find a bug in it, write a test. Over time you will get more of the older code under test.

Answer 4

If the old stuff has been working fine for years, creating the unit tests now is not mandatory unless you change something in the old stuff. Anyway, writing unit tests for the new parts is not at all pointless. The new parts are the ones most likely to contain bugs, and they are also the parts most likely to be changed or refactored.

Answer 5

You can start covering your current code and, if you have some time to spend, start covering core functionality of old code. Also you can ask your PM for some extra time for that=)

Answer 6

(for the lack of commenting ability) I think it is better than not to test at all. Not every snippet needs to be tested, but only what will be used by the programmer eventually. Testing the utilitiy functions that you use internally is good, but not required if you access everything through a clean API afterwards.