Is unit testing worth it for legacy software?

Tagged:

If they’re paying you to do it, do it. It’s not up to you to decide whether it’s worth it or not. It’s up to the people who own the code. They’re paying you to do it, so obviously it’s worth it to them.

As a software engineer, you just have to accept that a lot of the things you do not just “won’t be worth it,” but also won’t ever even see the light of day. Doesn’t matter to me. I code because I love to do it, I’m just happy that I can get paid well to do it.

Wrapping test coverage around a legacy codebase is to me an interesting problem, one I’d love to be able to spend a lot of time working out how to do. Unfortunately, companies don’t seem to understand the hazards caused by legacy code and want you to just keep charging forward on features without allowing you sufficient time for code cleanup and testing.

I’d say in the beginning, write ‘smoke tests’ that verify large pieces of functionality. Once you’re happy with the test suite at that level, move down to integration testing of feature-level concerns. Once you’re happy with that, dig into the individual classes and write unit tests for public methods.

Of course, get approval from the stakeholders before going against their stated wishes.