Re: Re: testing the domain model
"Caleb Cushing [email protected] [domaindrivendesign]" <[email protected]> Tue, 07 Jul 2015 00:18:24 +0000
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAAHKNRE+0W8_Vbv370eJH1x8OB9wEYbbjG5xK9mYZbdJ3kwLRg@mail.gmail.com> |
> > separating the state of an aggregate into its own class(es) may help to > increase testability. Gabriel Schenker describes the idea in one of his > blog posts: DDD – The aggregate | Gabriel Schenker's Blog > <https://lostechies.com/gabrielschenker/2015/05/25/ddd-the-aggregate/> > cool article, to expand on the problem though, we had done that, and certainly unit tests were easy enough to write. > In the case of submitting an application a typical precondition check could be to verify that only an application that is currently in status Draft can be submitted. The implementation could then look like this so there is lots of logic like this, for example you can do action only if your Users primary Organization is type Payer and the Test you are viewing is in status Active and and has an Effective Date of today starting today. to test this, I need a User, a Payer Organization, and a Test all populated enough to answer those questions. In another case I might have You can do action only if your Users primary Organization is type Payer and the Test you are viewing is in status is Review in which I would need those same entities but to flip the status to Review. so the problem becomes when you are constantly needing 2-4 entities with slightly different states, for different tests (lot's and lot's of integration tests), how can you populate this without duplicating lots of effort? -- Caleb Cushing http://xenoterracide.com