Re: Re: testing the domain model

I'll see if I can snag some samples at work tomorrow or later tonight.

Going roughly from memory... And this is a .NET system... We might have
something like this in our test setup:

TestFixture fixture = new TestFixture();
var firm = fixture.DefaultFirmFixture.DefaultFirm;
var matter = fixture.MatterFixture.CreateTestMatter("John", "Public");
...
service.BillFirmForMattwe(firm, matter);
...
Assert.IsTrue(...); // some post condition

Now one of the things that helped us tackle more domain testing was
applying Jimmy Nilsson's workspace pattern. The unit of work and
persistence boundary is abstracted in a way that our repository classes
exist in the domain and function just fine in tests. This is NOT an in
memory database or anything like that. There is no ORM in the domain or
test code. That's a rule we hold to purely.

For some of our tests, that doesn't come in to play, but for others, it
does.

On Tue, Jul 7, 2015, 5:59 PM Caleb Cushing [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>> I'm jumping in late,  but we've build test fixtures that our test classes
>> uses to conveniently stand up common entities like those. It's made testing
>> code that requires several related entities much, much easier to write. The
>> test fixtures we've built are built with an API that keeps test writers in
>> mind so it's easy to succinctly use from a test without getting bogged down
>> in boiler plate details.
>>
>
>  any chance you can share the design of that API (kind of what I'm looking
> for)? one of the problems we faced was that our first attempt at an API was
> married to Spring and an H2 Persistence Layer, which meant unit testing was
> harder, do you resolve anything like that?
>
> ,_._
>>
> --
> Caleb Cushing
>
> http://xenoterracide.com
>  
>