Re: Re: testing the domain model

>
>
> maybe you are searching for the wrong thing (as I did)?
> In order to ease the pain of testing you have to improve the design of the
> system under test.
> This one opened ma eyes:
> http://everzet.com/post/107204911916/economy-of-tests
>

That's true but since DDD is about managing complexity, and in some cases
we did have undue complexity... we still needed to test our business rules
which actually did revolve around complex, or multiple aggregates.

in some cases I had written simpler unit tests that could verify a
service + entity without any of the integration complexity. In others I
still had to wire those up.

I believe that a lot of our business logic got tested under selenium, which
was incredibly fragile, and expensive compared to how it could have gotten
tested.

Basically I know the difference between black box app testing, like
selenium, unit testing, functional testing (which tests more complex logic
but is not full integration testing) , and integration testing.

but none of that really codifies the patterns which are best for those. For
example the selenium code base was a mess, I simplified it by bringing Page
Objects into the mix. It is still a mess but now there's a route out of the
mess. Page Object is the pattern that fixed selenium, looking for the right
ones to fix Integration and Functional testing.

-- 
Caleb Cushing

http://xenoterracide.com