Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
Redundant coverage is a testing anti-pattern which describes the situation in which the behavior of a particular production code path is depended on by multiple tests. It's one (of several) examples in which greater code coverage is not a universally good thing.
Redundant coverage is problematic because a single desired change in a given bit of production code might result in a need to change numerous tests, who would otherwise fail (and as a false negative, at that).
For instance, if a system has a unit
DeterminesAdulthood which determines if a user is of majority age, and a later requirement changes the age of majority from 18 to 21, then any test which both exercises
DeterminesAdulthood and cares about whether users are adults may be impacted by the change.
This anti-pattern becomes a systemic problem under very common architectural patterns, such as in a multi-layered web application server like Ruby on Rails. If the above example had been implemented as a predicate method
adult? on a
User model, then a typical Rails test suite would be expected to redundantly cover
User's model test, controller test, and integration test, as well as in the analogous tests of any domain objects which depend on
User (which in a Rails application, is typically "all of them")
As a point of test design, then, finding a way to minimize redundant code coverage is considered a worthwhile goal. An advantage of London-school TDD is that its isolation test suites tend to significantly reduce redundant coverage; often, units in such systems are tested exactly twice: in their symmetrical unit test and in an integrated SAFE test.