testing legacy codes with phpunit

Question

I have a legacy codebase and I need to test that code with PHPUnit. So I am asking for suggestions based on your experiences. Which classes I should test first? Or give the priority?

Should I start with the easy/small classes or with the base/super class?

Answer 1

My general suggestion for introducing unit testing to an existing codebase would be the following:

1. Start of testing some very simple classes to get a feel for writing tests
2. Maybe even rewrite those tests again and make proper "this is how we should do it" examples out of them
3. Take the one of the biggest and meanest classes in the whole system and get that class tested as best as you can. This is an important step to show everyone in your team (and maybe management) that unit testing your codebase CAN WORK OUT and is doable.

After that I'd suggest that you focus on three things:

• Make sure new code gets tests
• If you fix a bug create a test before fixing it to "prove" the bug is actually fixed
• Use tests as a tool when you touch/change old code so you get better an better test coverage.

PHPUnit will provide you with a CodeCoverage Report showing you how well your codebase is tested. It can be pretty cool to see the number rise from 0.3% to 5% to 20% over the course of month but it not a really strong motivator.

To make sure you test NEW code I'd suggest using PHP_Change_Coverage as described in this blog posting

This tool will help you a lot generating meaningful coverage reports as it only shows NEWLY CREATED CODE as UNTESTED and not all the old stuff you have lying around.

With that you have something at hand that makes it really easy to "get a high % very early and keep testing the new stuff" while you create tests for everything old.

Before PHP Change Coverage:

and After:

Answer 2

There's often too much code in a system to test it all as a first step. But most of that code already works.

I'd start with methods that were modified recently. Presumably most of the rest of the software works to some degree, and testing that won't likely find as many errors as will be found in new or newly revised code.

Should you run out of work (I doubt it in the near future if you have 1 or more developers actively working near you), you can move up to methods that use the methods that were modified, to methods that have high complexity according to software metrics, and to methods that are critical for safe system operation (login with password, storage of customer charge data, etc.)

One way to help decide what to consider testing next is to use a test coverage tool. Normally one uses this to determine how well tested the software is, but if you don't have many tests you already know with it will tell you: your code isn't very well tested :-{ So there's no point in running it early in your test construction process. (As you get more tests you and your managers will eventually want to know this). However, test coverage tools also tend to provide complete lists of code that has been exercised or not as part of your tests, and that provides a clue as to what you should test node: code that has not been exercised.

Our SD PHP Test Coverage tool works with PHP and will provide this information, both through and interactive viewer and as a generated report. It will tell you which methods, classes, files, and subystems (by directory hierarchy) have been tested and to what degree. If the file named "login.php" hasn't been tested, you'll be able to easily see that. And that explicit view makes it much easier to intelligently decide what to test next, than simply guessing based on what you might know about the code.