TDD, DDD and Encapsulation

Question

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 u

Answer 1

Hey Justin, like you, I was recently thinking about adding getters to my write-only domain object for the sake of unit testing, but now I am convinced I was wrong. Assuming you've bought into the idea of a write-only domain in the first place, then if you have getters at all, you're asking for trouble. The write-only domain principle would want you to fire an event from your domain object, or read from a projection that your domain object wrote, or something like that. Once you expose getters you're starting to expose the object's "shape", and as Greg Young says, "Domain objects have Behavior, not Shape".

That being said, I am struggling with your same question ... how do you unit test a write-only domain object? Here's my current plan: I am thinking of making my Domain Object fire a Domain Event saying "These properties changed", and in my unit test, I'll register for it before I send the "EditCommand". Check out Udi Dahan's post on Domain Events here, and also see what Eric Evans says about Domain Events.

Answer 2

OK, this answer is one year too late ;-)

But when you want to test CQRS models, you can make assertions on the fired domain events instead of assertions on entity state.

e.g. if you want to test if calling : customer.Rename("Foo") results in the correct behavior.

Instead of test if customer.Name equals "foo", you rather test if there is a pending CustomerRename event with the value "Foo" in your pending event store. (in your uow or in your entity event list depending on implementation)

Answer 3

I was wondering the same thing until I finally stumbled upon the following papers. I found them to be great primers on performing behavior verification, especially the first one providing me several "aha moments":

1. Using Mocks and Tests to Design Role-Based Objects
2. Mock Roles, Not Objects

Answer 4

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.

Answer 5

A couple things.

First, when you do things like TDD to make your code testable you end up with smaller class. If you have a class with lots of private properties you can't inspect, theres a good chance it could be broken into multiple classes and made more testable.

Second, oldschool OO architecture tries to make software safe by using language safeguards to prevent things from being accessible. A TDD architecture makes software more robust by writing tests that verify what the code actually does, putting less emphasis on using language constructs to ensure what the program doesn't do.

Last, checking a property is not the only way to validate code did what it was supposed to do. The book xUnit Design Patterns documents other approaches here: http://xunitpatterns.com/Result%20Verification%20Patterns.html

Answer 6

I call a system's public input methods (i.e. I push input data into the system), and then I get (and assert) the system's output. I'm not testing the system's internal state, but rather its public/visible behaviour: Should one test internal implementation, or only test public behaviour?