Test-After Development Sins (Header Interfaces)

A series of articles exploring the impact of writing tests after the code is written on the implementation part of SDLC.

Sin No.2: Header Interfaces.

A good example is a data access layer combined with the use of an Object-relational mapper (ORM).

While an ORM provides (out of the box) a collection-like interface (ISession, DbContext) for accessing domain objects, most of the time a coarse-grained Header Interface is created on top of that.

Those interfaces usually contain high number of members making the overall architecture extremely inflexible.

The system is usually forced to live with only one implementation for each interface. That implementation is most of the times generalized.

Some examples,

• It's nearly impossible, in performance related scenarios, to manually execute SQL or access the IDbConnection.

• In order to map data between application boundaries or populate an instance of a view model the exact same implementation is used.

In the second example, the implementation eagerly loads all the entities of an Aggregate Root which hurts performance.