Registering Concrete Classes in DI Can Lock Out Unit Testing, Developers Warned

A software development discussion highlights a subtle but costly mistake in Dependency Injection (DI) setup: registering a concrete class directly instead of mapping it to an interface. While both approaches compile and run correctly at runtime, only interface-based registration allows controllers to be unit tested in isolation, since mock or fake implementations can only substitute for interfaces. When a controller's constructor demands a specific concrete class, developers are forced to test against a real database connection, making tests slower and less reliable. The problem often goes unnoticed early in a project because it produces no errors or warnings, but retrofitting interfaces later requires changes across every constructor and registration that references the class. Defining an interface upfront costs minimal effort and is considered standard good practice in ASP.NET Core projects, preserving testability without future codebase disruption.