David makes some interesting points.

As I said a moment ago, I like to avoid factory methods in the text
fixture. But I'd be open minded if the project had well-defined
aggregates and the factory method was creating one, to be tested as a
whole. (Of course, that factory behavior might also be useful to the
app, so perhaps it could be the basis of a separate factory).
Unfortunately, what I more often see with those factory methods in tests
is that they are compensating for the lack of clear aggregate boundaries.

Also a good point about domain services tending to have legitimate
dependencies, hence mocking them makes sense in many tests. For example,
in timeandmoney, the "TimeSource" interface enables this approach. Most
real TimeSource implementations are coupled to something external to the
program (the system clock, an Internet time service) and you don't want
that intruding on your tests. To test application logic that uses a
TimeSource, you need a dummy of some kind that returns a known value and
doesn't make the test dependent on some external resource (even though
the live program will be).

Interesting description of testing the factories by giving them mocks to
assemble. (If I understood.) The upside of that would be to discourage
the factory from becoming more than a factory.

They are necessary some times, and can be used well, but I still see
mocks more often covering up model/design problems.

Eric

P.S. By the way, I prefer not to put factory methods in the repository.
Seems to blur its responsibility of being the access point for obtaining
preexisting objects. Factories make new objects.



David Laribee wrote:
>
>
>
> I treat the Aggregate as a unit. It's simply inelegant, IMHO, to
> create seams for collections, etc. I generally state test my
> Aggregates. You'll end up with a fixture-per-aggregate. A couple of
> strategically placed Factory Method inside your test fixture ( e.g.
> GetCustomerForThisScenario()) will do wonders for your sanity / test
> lengths. I tend to use what I call Testable Mask when things get hard
> to verify. That is, protected fields in the entity/aggregate that you
> can expose via a subclass where you perform the test.
>
> I treat Domain Services as a unit and test them in a mock style. I try
> to keep my tests down to one mock object and however many stubs
> (sometimes domain services have a number of dependencies).
>
> .
> _,___