Developer Testing: The Legacy Code Dilemma, Modified Condition Decision Coverage, and Pairwise Testing

Construx Senior Fellow Melvin Perez-Cedano and host Mark Griffin dive into developer testing in response to a recent engagement with a telecommunications client trying to improve quality and productivity.

As developers, we know that we’re going to make mistakes. The point of developer testing is to discover those mistakes as early as possible so that we can remove them when it is far more economical to do so. Test-driven development (TDD) and behavior-driven development help here. Plus, writing test cases first helps us clarify our understanding of what we need to do before we write the code. But the overall point is to decrease the gap in time between defect insertion and defect removal. Even testing after you write a function helps you in this regard.

The most common question in our developer testing engagements is this: How do we apply these techniques to the existing code that we have, to our legacy code that was not designed to be testable? Melvin describes how to change the future of this extremely valuable code. For example, minimize manual integration to minimize the risk of changes.

Melvin continues by describing a concept during the engagement that the attendees at first struggled with: modified condition decision coverage (MCDC). The technique provides a level of test coverage that is required when you’re building safety-critical software that requires high reliability. (This was appropriate for this engagement because the company is involved with self-driving cars.) Typically, across the industry, when 80% of line coverage is achieved, the testing is considered good, but this definitely isn’t always sufficient. MCDC vastly improves your coverage by testing every condition independently.

Our final topic today, which was of particular interest in this engagement, is how to test configurations with multiple factors: different network protocols, different operating systems, different databases, different UIs, etc. When you try to have complete coverage in this environment, the number of required test cases grows rapidly and the cost of testing increases similarly. Pairwise testing lets you provide wiser coverage when total coverage is likely impossible. The number of test cases is reduced significantly, but the crucial coverage is assured. To have strong confidence without investing half the project in testing, this method is invaluable.