The repository itself is not usually tested?

Repository interface belongs to domain layer. But implementation belongs to infrastructure or data access layer. This implementation is usually not tested with unit test. It uses ORM API heavily, so it is extremely hard and wasteful to test repository in isolation. This problem is not specific to repositories: Don’t mock types you don’t own.

Repository should be tested with integration tests, using real ORM. In memory database is a very popular approach to this problem.

… Because if I use a fake
implementation of my context/session I’m not doing real tests?

Even if you manage to make it (which I really doubt in NHibernate’s case) you will be wasting your time. Session/Context interface is out of your control and your test would just reiterate your guess about how the real thing will work.

Becausethe context/session itself is the repository?

No. Context/Session is implementation of UnitOfWork pattern. It is not part of your domain. This is infrastructure.

The repository pattern with EF or NH is like a wrapper only?

Repository is important domain concept, it is not just a ‘wrapper’. Just like your application is not a ‘wrapper’ over the database. I think that DDD repository interface definition should be based on Ubiquitous Language as much as possible and should not include any ORM related words or types.

Leave a Comment