Re: Re: testing the domain model

On Tue, Jul 7, 2015 at 5:10 PM Brian Sayatovic [email protected]
[domaindrivendesign] <[email protected]> wrote:

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

>  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.
>
yeah our entities didn't really require it. I mean they were hibernate
based entities... but you could have tested most things without saving
them. I think that it was just a mistake that someone decided to put
"saves" into our test fixtures.

thanks for the sample code it's helpful.
-- 
Caleb Cushing

http://xenoterracide.com