The legacy testing dilemma

Imagine you’ve just entered the workforce as a software developer, or just started a new dev job. You were told that your first project will be a game changer for the company. Instead, your new boss hits you with a 5 year old legacy MVC project that’s been passed down from generation to generation of junior devs.

How do you feel? despair…? frustration…?

You know that you need to work with new code, build new things, and try new techniques to learn them and advance your career.

This is especially true for testing. Testing is definitely a ubiquitous skill for developers who want to advance their career.

The issue, then, is how do you develop your testing skills while working on a project that

Test in Parallel with Other Changes

The key to really taking your testing skills to the next level, given the cards you’ve been dealt, is to use testing to facilitate some other change you need to make to the code.

For example, adding a feature. A feature is going to affect the existing code in some way. Test the parts of the code that you’re going to have to touch when you start working on a feature.

Another example, a bug fix. A bug fix is going to force you to execute some pieces of code in isolation to diagnose the root cause of the issues. Write tests for those pieces of code.

This goes for refactorings and optimizations as well.

The key is not to look at a legacy codebase and try to find places to write tests. In huge, complex codebase - you’ll likely choose the wrong tests to write if you’re only focused on coverage. If you focus on other tasks related to the maintenance or enhancement of the project when it comes to testing, you’ll gain value from those tests.

Gaining value from automated testing is your number one concern. Don’t just test to satisfy some coverage metric, keep your eye on the prize.

Speaking of prize…

My ebook: Intuitive Testing with Legacy ASP.NET MVC is launching soon! It will address this very situation and then some… so be sure to keep an eye out!