Is Unit Testing worth the effort, in a large and old (5yr) codebase?

Question

I've just joined a team which has been working in a main-always mode for the last 5 yrs (java, maven based project). Consequently plans to leverage unit testing have always been in the pipeline, never materialising (so far). A Great dev team has ensured that code quality is generally good, and there aren't structural code issues, but there's just no culture of writing jnuit tests. But I, having seen the benefits of unit testing, am a lone warrior here pushing for adoption of auto-testing.

The team layout is such that a separate testing team does manual testing of functionality before rolling out the code, and a change management team is a checkgate for change approvals and builds (no continuous integration either, so far).

Following are the hurdles: Because the code base is huge,and some of the original developers have left the team, any additional unit tests may be too little, too late. Add to it that I may be the only one pushing for unit testing. Though my manager has been supportive of the idea, he doesnt want the change team to be bogged down by additional time required for the tests to run.

I'm of the opinion that a stand-alone CI tool can be used to start off with, and the change team must alter their scripts to skip tests, as and when they are added.

What would you do in my shoes?

P.S.: I'm aware of a similar question on stackoverflow , but in this one, the aim is to convince the different stakeholders and the best path to takel; not a technology comparison.

Answer 1

It would be worth writing tests to test specific functionality that you are working on and you want to remain stable.

With a large existing application that has no test coverage at the moment, you wouldn't want to sit down and write tests all in one go in order to get 100% unit test coverage and you never will. You'd just single out specific functionality for testing. I don't think there's such a thing as too little or too late; unit tests for only a tiny bit of very important functionality is better than none at all, and some unit tests now are better than no unit tests ever.

Answer 2

Unit testing is advantageous even in an old project, for example, by establishing unit tests, you can be sure that the problem is not in existing code but in new code (even if you have a QA process, bugs do still get through on occassion). Additionally, they prevent changes to old code from introducing subtle differences in behavior. Also, unit tests document the intended behavior of the huge codebase.

Now, adopting large changes are never easy. The first and most straightforward thing is to mandate unit testing of all new code, so that the effort and workload of unit testing the old codebase doesn't continue to pile up. Then, the second part is to take the initiative, and create some unit tests for the old code. If you do that, then you should be able to convince other members of your team to help with the effort in creating unit tests for existing code. If necessary, come up with fun incentives, like promising a pizza party for the team that creates the largest number of unit tests for the existing code base.

Also, remind your teammates that this isn't something where they need to drop everything that they are doing... if they only create one unit test for an existing component each day on top of their other work, then eventually you will get a unit test for all the existing components in your codebase.

Answer 3

Sounds like you have a pretty good handle on the situation.

Two things:

1. Don't expect to be able to fully unit test a 5 year old project. Assuming 5 developers working for 5 years, you're in the neighborhood of 50,000 programmer-hours. Assuming that tests take as much time to write as code, you'd be doing pretty good to get 2-3% coverage in a year.

2. So: Test new code, and write tests for modifications of older code. Get time / take time to set up CI of some kind. Gradually, you'll build up a nice battery of tests.

Since you're apparently not drowning in bugs, start slow, gain momentum.

Answer 4

IMHO, unit tests or any other tests for that matter (except for functional tests) should be run frequently against parts of the application that are critical and volatile, at the same time. In other words, unit tests should not be written for the sake of writing tests, but rather to ensure tha the development/maintenance engineers do not trip over certain conditions in code.

That said, you might also want to take a look at integration tests that run in a CI server, more so because they're closer to the functional tests, and also because the code is mature. From my observations, identifying unit tests to write in a mature application is far difficult and has lesser RoI in the shorter term than integration tests.

Integration tests in your case will ensure that the various tiers of the application continue to be held together with the intentions of the original developers. Unit tests on the other hand, being a bit more localized in nature will ensure that any new patch/bug fix in a particular area does cause side effects in that location.

Answer 5

It will be a massive effort and returns would be small. Rather automate and expand your current testing to ensure system stability (I assume there is some testing at system level). I think you should focus on parts of the system that still see lots of change or that you plan on changing in the near future.

Unit testing is good but can be difficult to retrofit into an existing system. If you just focus on unit testing for the next year or more you are going to lose forward momentum.

Answer 6

I would not write tests just to write tests. What would be the business payoff? Your business has likely already suffered the effects of not having unit tests and now the issues have been addressed. If I did add tests, I would only add them to the sections of code that would cause the most unpleasant results. For example, I'd consider adding testing to any role/security related code.