Bringing unit testing to an existing project

Question

I'm working on an existing JEE project with various maven modules that are developed in Eclipse, bundled together and deployed on JBoss using Java 1.6. I have the opportunity to prepare any framework and document how unit testing should be brought to the project.

Can you offer any advice on...

• JUnit is where I expect to start, is this still the defacto choice for the Java dev?
• Any mocking frameworks worth setting as standard? JMock?
• Any rules that should be set - code coverage, or making sure it's unit rather than integration tests.
• Any tools to generate fancy looking outputs for Project Managers to fawn over?

Anything else? Thanks in advance.

Answer 1

If you haven't done so already, read Working Effectively with Legacy Code by Michael Feathers.

Answer 2

I've been retrofitting unit tests to a C++ project and it is not pleasant.

First thing I did was to identify where most of the 'action' occurs. Then use that to start putting unit tests on the functions that can be test easily.

Then once you have the easier ones you can start looking at expanding the coverage virally - attack the functions that have fewer dependancies, run through them a few times in a debugger seeing what values are passed in and then write unit tests with those values to make sure you don't break anything.

Don't expect a quick fix - it's taken 3 weeks (6hr days, 5 days a week) to get 20% coverage but the code spends 80% of the time in that code so I think it has been time well spent and has uncovered quite a few bugs.

Answer 3

Regarding test coverage, I think that when you're bringing in unit testing to an existing project it's too early to start setting coverage expectations. You should start by ensuring that you actually can integrate the test framework and get reports from the coverage tools. Once you've done that you can start monitoring coverage, and then you can consider targets.

Answer 4

Concerning the unit testing framework, there are mainly two of them : jUnit and TestNG. Both have theuir advantages, and both are equally performant. The main dvantage of jUnit is (to my mind) its default incoproration of an Eclipse plugin allowing easy tests calling.

Concerning the mocking framework, I don't find them to be a required part of your testing approach. Of course they're useful, but they solve a specific purpose : testing a behaviour (as opposite to testing an interface - what jUnit allows. With mocking frameworks, you're able to test how a specific class implements a specific interface. Will you need it ? Obviously. Will you need it first ? I don't know.

Concerning the rules, the only one I've found to be useful is simple (as always) : "always test code that broke at least once.". Consider your bug tracker. Each time a bug is encountered, there must be a unit test ensuring there is no regression. It's, to my mind, the faster way to have quality code.

Concerning the fancy- and efficient - output, I can recommend you enough to install a continous integration server (Hudson, obviously). It will run all your test suite each time code is commited, to ensure there are no side effects. it will generate graphs shoiwing the number of test run, and so on. it also can integrate code coverage tools and graphs. This continuous integration server will really become fast your testing buddy.

Answer 5

This is a complex question, so just a few notes about our practice at $work:

• JUnit is indeed still the standard. Most documentation and literature treats JUnit.
• Mockito seems to be the new star in Java mocking, although we still use JMock and think it's fine for our needs.
• We use the EclEmma Eclipse plugin for checking our test coverage, and like it.

Answer 6

Any tools to generate fancy looking outputs for Project Managers to fawn over?

Be careful. A fancy tool for displaying metrics on unit test counts, coverage, code quality metrics, line counts, check-in counts and so on can be dangerous in the hands of some project managers. A project manager (who is not in touch with the realities of software development) can get obsessed with the metrics, and fail to realize that:

• they don't give the real picture of the project's health and progress, and

• they can give a completely false picture of the performance of individual team members.

You can get silly situations where a manager gives the developers the message that they should (for example) try to achieve maximal unit test coverage for code where this is simply not warranted. Time is spent on pointless work, the important work doesn't get done, and deadlines are missed.

Any rules that should be set - code coverage, or making sure it's unit rather than integration tests.

• Code coverage is more important for parts of the code that are likely to be fragile / buggy. Don't mandate any benchmark coverage level.

• Unit tests versus integration tests depends on the nature and complexity of the system you are building.

• Adding lots of unit level tests after the fact is probably a waste of time. It should only be done for class identified as being problematic / needing maintenance work.

• Adding integration level tests after the fact is useful, especially if the projects original developers are no longer around. A decent integration test suite helps to increase your confidence that some change does not break important system functionality. But this needs to be done judiciously. A test suite that tests the N-th degree of a website's look and feel can be a nightmare to maintain ... and impediment to progress.