i checked out the fowler article and the definitions he cites for mock, stub, fake and dummy are quite similar to those Nilsson cites. all the examples of fakes that I've seen appear to leverage an interface. i guess my question is what would the implementation of a fake look like in the context of an entity that didn't leverage an interface. so, from my earlier example of testing some service method that accepts an instance of a Document entity...would a fake be a sub-class of the Document entity itself or a subclass of the base class the document entity is based on. it would seem that whatever it is it's got to be something that the service method will recognize as a Document entity or it won't compile. alternatively, could the service rely on an abstract base class that would be implemented by the Document entity and the fake as well? would either/both of these make sense?
On Fri, May 1, 2009 at 11:00 AM, Greg Young <[email protected]> wrote: > > Mocks aren't stubs, Fowler. > http://martinfowler.com/articles/mocksArentStubs.html > > > > On Fri, May 1, 2009 at 10:41 AM, Everett Muniz <[email protected]> > wrote: > > @greg, thanks for the feedback, it's much appreciated. > > i may be mixing up terminology or I may just be all wet. when I say I > > started at the behaviors, I mean that I started with things the software > > will do that spans multiple domain objects. in my case one of those > > application behaviors is generating an image from an object graph that > > contains shape objects. each discreet shape does indeed contain behavior > > that's relevant to it and/or the aggregate it's a part of. > > as far as fakes, i'm not clear on what's meant, can anybody offer a > > succinct, concrete example of a fake. Nilsson's book describes stubs, > fakes > > and mocks on page 164 but his example is using repositories with > interfaces > > and I'm interested in what a fake would look like in the case of an > entity / > > value object. for instance, if you're testing some service method that > > accepts an instance of Document entity how would a fake be created? > > thanks again. > > > > On Fri, May 1, 2009 at 10:13 AM, Greg Young <[email protected]> > wrote: > >> > >> > Could you unpack that a bit further? Are you suggesting that > >> > applicability > >> > of interfaces is primarily around behavior rather than as a means to > >> > describe the entities and value-types? I started the project working > on > >> > the > >> > behavioral aspects and it was convenient for testing to rough in the > >> > domain > >> > objects being acted on by those behaviors as interfaces. So, I > suspect > >> > that > >> > may fall into the category of anti-pattern if I'm understanding you > >> > right. > >> > >> shouldn't the behaviors be in the domain objects themselves? > >> > >> Beyond that there is almost nothing to gain by putting the interfaces > >> around them. It may seem easier when writing tests but when dealing > >> with those kinds of tests you are probably better off dfealing with > >> the real objects anyways (fakes). > >> > >> Cheers, > >> > >> Greg > >> > >> On Fri, May 1, 2009 at 10:03 AM, Everett Muniz <[email protected]> > >> wrote: > >> > Could you unpack that a bit further? Are you suggesting that > >> > applicability > >> > of interfaces is primarily around behavior rather than as a means to > >> > describe the entities and value-types? I started the project working > on > >> > the > >> > behavioral aspects and it was convenient for testing to rough in the > >> > domain > >> > objects being acted on by those behaviors as interfaces. So, I > suspect > >> > that > >> > may fall into the category of anti-pattern if I'm understanding you > >> > right. > >> > On Fri, May 1, 2009 at 9:42 AM, Greg Young <[email protected]> > >> > wrote: > >> >> > >> >> Are you interfaces like ICustomer IOrder etc or are they behavioral / > >> >> use case based? > >> >> > >> >> the former is most likely an anti-pattern. > >> >> > >> >> Greg > >> >> > >> >> On Thu, Apr 30, 2009 at 6:51 PM, everettmuniz < > [email protected]> > >> >> wrote: > >> >> > > >> >> > For those of you using NHibernate in DDD projects do you structure > >> >> > your factory and repository methods to return/accept interfaces or > >> >> > their implementations? I've written the domain model and service > >> >> > layer in my current project to rely heavily on interfaces rather > than > >> >> > implementations but given that NHibernate maps to classes and not > >> >> > interfaces it seems like it may make more sense to structure the > >> >> > factories / repositories to at least work with classes rather than > >> >> > the > >> >> > interfaces they're based on. > >> >> > > >> >> > > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> It is the mark of an educated mind to be able to entertain a thought > >> >> without accepting it. > >> >> > >> >> > >> > > >> > > >> > > > >> > > >> > >> > >> > >> -- > >> It is the mark of an educated mind to be able to entertain a thought > >> without accepting it. > >> > >> > > > > > > > > > > > > > -- > It is the mark of an educated mind to be able to entertain a thought > without accepting it. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
