Many of the readings I’ve done on DDD, both in books and online, seem to represent code that, often times, is difficult or impossible to unit test. For example, there are numerous samples with static factories, calls to concrete domain classes and static extension methods (in C# samples only). I find it frustrating and taxing to have to constantly re-evaluate the code to make it testable in my mind.
Can anyone suggest material that demonstrates DDD code with 100% testability in mind (preferably in C#)?
Also, to meander a bit:
Is the fact that many of the code samples are not test-friendly a sign (smell) that DDD is becoming antiquated?
Is the fact that many of the code samples are not test-friendly a sign
(smell) that DDD is becoming antiquated?
I don’t believe that. I would say that it’s a sign that whoever has given the smelly DDD code samples was focused on that and not unit testing. It’s not difficult to morph that code into that which is crafted with those ends in mind.
Now I don’t mean to toot my own horn too much, but feel free take a look at this question and my answer over at Code Review. I think I took some fairly common DDD code and whipped it into at least a more testable state (maybe not 100% testability, but definitely more so).
I’ve also attended a couple DDD presentations from from Stephen A. Bohlen and here’s a blog entry with a link to some of his code and slides. I’ve taken that code and did some refactoring much like I did on the CR answer.
Isn’t DDD essentially ‘top down’ you design and refine a model based on domain knowledge/experience.
Whereas TDD is ‘bottom up’ program design is influenced by the refactoring process and encouraging decoupling to enhance test-ability.
So as these are at odd’s with each other… I believe it’s hard to demonstrate DDD code with 100% test-ability.
I believe that it’s impossible to reach a 100% test-ability, so i always pursuit a 70-90%.