Just to expound on your hypothesis (from another OOP TDD-ish proponent): Google defines Cyclomatic Complexity as "a software metric... [that] is a quantitative

Just to expound on your hypothesis (from another OOP TDD-ish proponent): Google defines Cyclomatic Complexity as "a software metric... [that] is a quantitative measure of the number of linearly independent paths through a program's source code." It seems to me that swapping out a dependency, abstracting it, and then feeding multiple variants of the same dependency to some code would greatly increase the number of linearly independent paths through the code. These kinds of refactorings/improvements also tend to greatly increase maintainability, clarity, flexibility, and your programs featureset... By way of example: taking some DB insert code and updating it write to a simplified interface and then injecting components to handle writing to the DB, a local file for testing, AWS S3, and such... A well-factored, clean, reusable, persistence ignorant solution will have a higher cyclomatic complexity than a hard-coded, raw, INSERT. I know which one I want to maintain, though ;)