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 -~----------~----~----~----~------~----~------~--~---
