How to retroactively add tests to a code base?

Question

Suppose you are tasked with adding a testing framework to an existing code base that has very very little unit testing coverage. The code base isn't insanely large yet, however, it does have areas where it's not super clean, or not very OOP or testable.

I've read a couple of good answers:

• Adding unit tests to legacy code
• How to approach unit testing in a large project
• Best Option for Retrospective application of TDD into C# codebase

But the project I'm working on is an Android app, so it's slightly different (given lots more UI components).

I have some questions that all relate to the same issue:

1. What's the best way to do go back and put a bunch of tests in place?
2. How do I prioritize which parts to test first?
   • do I start with areas where it's getting called a lot (and is there a tool for code analysis like this)?
   • or do I go back and look at classes which in the past have had the most number of bugs?
3. Should I write integration tests first (given this is an Android app and also integration tests may prevent broken unit tests/refactorings) and then work in the unit tests?

Sorry for all the questions, just really looking for a good approach, more specifically geared towards retrospectively testing an Android app.

P.S. I'm curious if people know of good tools they can use for code analysis that can help bring to attention the areas in a code base in which unit testing would be most helpful.

Answer 1

Usually when starting with unit testing on an existing application you would want to do it iteratively - you probably do not have the time or the man power for a big upfront investment and so you want to add unit tests as part of the required work:

1. Write unt tests When adding a new feature - or better yet use TDD
2. When fixing a bug - write unit test(s) that fails de to the bug before fixing it
3. When refactoring old code wriute unit tests to make sure no regression bus were introduced

Id the whole team follow the three steps above in a matter of weeks you should have good coverage for the code you've been changing - depending on the size of the project.

Answer 2

I don't have an Android-specific answer. I hope someone comes along and adds a good one. Meanwhile: write acceptance (integration) tests for your most important features (from your product owner's point of view, not from some tool's). You'll get the most coverage for your effort, and be the most likely to prevent bugs that customers care about. Don't worry so much about unit tests; those are for details.

[That's the answer given in the third post you cite, but we're still waiting for that Android-savvy answer so let's not call this a duplicate yet.]

Do write acceptance tests and, as necessary, unit tests for new features, and write unit tests when fixing bugs.

Regarding how to find areas of the code that need tests, the first thing to do is measure code coverage. (You can do that in the Android SDK with ant emma debug install test.) Obviously code with no coverage needs tests.