retroactive phpUnit testing: is it worth it?

Question

We have about seven different websites that we have developed in-house. They're sites that track different HR applications and help some of our people get their jobs done via scheduling. Today, the head software designer told me to start writing test cases using phpUnit for our existing code. Our main website has at least a million lines of code and the other websites are all offshoots of that, probably in the tens of thousands to hundreds of thousands of lines.

None of this code was written through any apparent design method. Is it worth it for us to actually go back through all of the code and apply phpUnit testing to it? I feel that if we wanted to do this, we probably should have been doing it from the start. Also, if we do decide to start doing this unit testing, shouldn't we adopt TDD from here on? I know for a fact that it will not be a priority.

tl;dr: I've been told to write post-rollout test cases for existing code, but I know that the existing code and future code has not been/will not be created with the principles of TDD in mind. Is it worth it? Is it feasible?

Answer 1

You probably wont be able to test the code in it's current form. It's not just throwing tests to some poorly witten code cause that code probably is not testable.

To be able to write the tests you probably will need to refactor the code. Depending on the quality of the code it could mean rewrite it entirely.

I'd recommend test only the new additions to the code. So if you need a new method in a class or a new function or whatever, it must be tested. Personally I prefer TDD but to people new on testing it can be too much to make them think on a test even before having refactored the code. So you can stick to test later.

For testing the new additions, you'll need to do some refactoring on existing code. For example, if you add a method that logs info, the logger should be injected to allow stubbing it. So you should write some kind of container. Now it does not mean that everywhere the logger is used you have to inject it. Just in the places that you're adding or changing something and that must be tested. This can become quite tricky and require someone well versed in testing to assist.

In short, my recommendation is:

• test only the new additions and the new code
• refactor the code to be sure that the code under test is really testable
• see if the tests give confidence and are worth the effort and keep going

Answer 2

Automated tests are an extremely good idea for when you want to refactor or rewrite code. If you have a PHPUnit test for a function or class you can rewrite the code then confirm using the test that the code still functions the same as it did before. Otherwise you can end up breaking other parts of your code when you refactor or rewrite stuff.

Answer 3

Do you still change the code? Then you will benefit from writing tests.

The harder question is: What to test first? One possible answer would be: Test the code that you are about to change, before you change it.

You cannot test all your code years after it has been written. This will likely cost too much time and money for the generated benefit your company would gain.

Also, it is very hard to "just start with PHPUnit", the benefits for such an approach are probably not that great for the first few months or years, because you'd still test very small units of code without being able to also check if the whole system works. You should also start with end-to-end tests that use a virtual browser that is "clicking" on your pages and expects some text to be displayed. Search keywords would be "Selenium" or "Behat".

I know that the existing code and future code has not been/will not be created with the principles of TDD in mind

It's a question of attitude of all the developers what will happen in the future. For existing code without tests, they likely will never happen. New code, written by unwilling developers, will also not be tested. But willing developers can make a difference.

Note that this takes more than just the lead software designer telling the team to start testing. You'd have to be coached and need a proper professional help if you haven't done it before, and if there is no infrastructure that constantly runs these tests to ensure they still work. Setting this all up means quite an effort, and if the lead software designer or any higher boss is ready to spend time and money on this, you should consider yourself very happy because you can learn something and build more reliable software.

If not, that approach will likely turn out to fail because of passive aggressive denial.