Menu
After several years of following the bad practice handed down from 'architects' at my place of work and thinking that there must be a better way, I've recently been reading up around TDD and DDD and I think the principles and practices would be a great fit for the complexity of the software we write.
However, many of the TDD samples I have seen call a method on the domain object and then test properties of the object to ensure the behaviour executed correctly.
On the other hand, several respected people in the industry (Greg Young most noticeably so with his talks on CQRS) advocate fully encapsulating each domain object by removing all the 'getters'.
My question therefore is: How does one test the functionality of a domain object if it is forbidden to retrieve its state?
I believe I am missing something fundamental so please feel free to call me an idiot and enlighten me - any guidance would be greatly appreciated.
685
Ultimately though TDD is about creating code that can be tested. DDD is a far more abstract philosophy and set of design patterns that addresses how to design a large, scalable, and maintainable system.
DDD places an emphasis on minimizing the translation between business people (domain experts) and software developers. By having more understanding of the domain, we can embed that knowledge as tests in our code. This implies that our code must somehow match how the business works.
What you're describing is state verification wherein you Assert on the state of the domain object. There's a branch of TDD that is called behavior verification that utilizes Mock objects.
Behavior verification allows you to specify which methods should be called and if you want, which methods aren't called.
Look into this article by Martin Fowler for more details: Mocks Aren't Stubs.
144
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
