I recently started development on a. NET project that will be making hearty (I meant to say heavy, but I think I like hearty better :-) ) use of test driven development (TDD) and domain driven design (DDD). I've noticed a couple things over the fist few weeks of development that I wanted to make note of. This entry will focus on how separating data operations into repositories improves the testing experience.
The first thing I've noticed is that following the design "guidelines" within DDD, specifically in regards to encapsulating data retrieval and persistence within repositories, makes writing unit test for database related activities much smoother. In previous projects rather then separating all data access in repositories I had methods on my domain objects, such as FindAll(), FindOne(), and .Save(). Since each domain object provided the interface for performing the data operations I ended having test classes for each domain object that did the testing of these data operations. Since many of the classes had dependencies (fk relationships) with other classes in the domain the tests for my domain objects required a lot of setup. My test classes ended up using domain objects that the domain object I was testing were dependent on. By separating all data operations into a repository, my test class can handle setting up all data necessary. Since this all occurs in a single test class it reduces the duplicated logic that previously appeared in a bunch of the test classes for the individual domain objects. Overall it's made the process much smoother and has led to cleaner test code, and more importantly cleaner code within my domain model.