The 'Interface Tax': How Over-reliance on Mocks May Be Stifling Development Speed

CodeOpinion
#software-architecture #testing #developer-velocity #design-patterns #dependency-injection

Following up on a contentious claim that “clean architecture was killing velocity,” a recent video addresses the primary pushback: testing. Many developers advocate for creating interfaces or abstractions specifically for testing purposes. However, the presenter argues this common practice, dubbed the “interface tax,” is a bad assumption. The core premise is that “testing needs a seam,” but that seam doesn’t automatically necessitate an interface. This was illustrated with a stereotypical VIN decoder service example, which converts a Vehicle Identification Number into year, make, and model information by making an HTTP API call. The typical approach involves defining an IVinDecoderService interface, which a concrete VinDecoderService implements, injecting an HttpClient. Application code then injects this interface, enabling easy mocking for testing the application logic.

While this interface-driven mocking appears clean and testable, the presenter highlights its inefficiency: an interface with one implementation and one usage, created solely for testing. Instead, the focus shifts to identifying the actual seam for testing. For the VinDecoderService itself, the seam is HTTP. Testing can be achieved by injecting a custom HttpMessageHandler into the HttpClient, which deterministically returns specific JSON payloads, verifying deserialization and mapping without an interface. For testing application code that uses the VinDecoderService, a “fixture” can encapsulate the setup of the concrete VinDecoderService with its custom HttpMessageHandler. This allows deterministic testing of application logic without exposing the HTTP dependency directly or requiring a mocking library. Furthermore, for single-operation classes, a delegate (function) can serve as an even simpler abstraction, allowing direct injection of test implementations. The key takeaway is to align the testing seam with the problem, rather than dogmatically defaulting to interfaces and mocking frameworks.