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