If you read my last post, I explain how I solved a really stupid problem of managing a Traffic Light using OOP principles and the concept of Domain Events, now I want to emphasize some of the advantages you have using this approach.
One benefit is in unit testing, suppose you want to test that a traffic light in red state does not cancel the request of another Traffic Light that want to become green.
This test is really simple, thanks to a simple factory, I’m able to create a traffic light in red state, then create a MayITurnGreen message and pass to the MayITurnGreen() method of TrafficLight. The test is really simple, but I want to emphasize the assertions.
I’m inheriting this test class from a base test class that register itself for Domain Events and the last event is always stored in the _domainEvent field of the test class. This permits to assert not only that msg.Cancelled is false (when a Traffic Light is in red status it should not prevent other Traffic Light to become green), but I’m able to assert also that no Domain Event were raised during this request.
This kind of testing is really important, because since Domain Events capture important events occurred in the past, being able to assert on them means that you are able to assert on every important event that happened to the domain during the test (this is really powerful). Let’s see another test
As you can see this test verify that, when 15 seconds are passed (this test is based on green time of 10 seconds) and someone ask to a Traffic Light in Green Status if it can become Green, it answers NO(cancelled == true), but also it become YellowFixed because 10 seconds are passed and it can become red to permit other Traffic Light to become green after yellow time will pass.
As you can see, the OOP and DDD approach can even simplify your tests.