I think we should be careful before making statements like "opaque
dependencies are bad" because there is absolutely a trade off involved
with them

Opaque dependencies can really be a good thing in terms of
encapsulation and in minimizing complexity to use your objects.



Do I as a caller need to understand the dependencies of an object in
order to use it? Do those dependencies have any meaning in my calling
context or only within the context of that object?



Messaging is a great way of introducing opaque dependencies without
really coupling your system ....




On Mon, Apr 21, 2008 at 9:21 AM, Chad Myers <chad@...> wrote:
>
>
>
>
>
>
> (new topic)
>
> Hrm, I disagree with some of those design constraints you said, or rather,
> I think they're addressed better using other means (perhaps Rhino is
> exposing a design smell?)
>
> RE: Static Methods
> I've already come to the conclusion that static classes/methods that have
> serious biz logic and 'new'-up dependencies are evil anyhow, whether I'm
> using mocks or not... heck, whether I'm even doing unit testing or not.
>
> RE: IOC
> IOC doesn't come into my testing experience at all. That's kinda the point.
> I write decoupled code with interfaces as the barriers so I can test
> components individually and independently. I might use an Auto-mocking
> container (mini-IOC) to help keep my tests cleaner and keep some of the
> mocking minutiae out of my tests, but only as an accelerator.
>
> If you're thinking about IOC or your IOC container while you're doing TDD,
> you're probably doing something wrong.
>
> RE: Public methods
> First, you shouldn't be hiding opaque dependencies inside your class
> anyhow, let alone private/protected internal/internal methods.
>
> Second, I have learned, under great pain, that only about 5% of the time I
> think something should be private/protected/internal does it actually need
> to be so. The other 95% of the time when I think that, it ends up better
> being public or moved into somewhere more appropriate anyhow.
>
> It's interesting how, since using TDD, it's been forcing me to see the
> API's I write from an API consumer's point of view and so I instantly feel
> the pain of p/pi/i methods and recognize the smell that they USUALLY (not
> always) represent and refactor appropriately.
>
> RE: Abstract methods
> Like above, I've found myself writing a LOT less abstract base classes and
> using a LOT more composition. I don't think I really truly groked
> 'composition over inheritance' until I started using TDD -- if for no other
> reason than TDD forced me to use more API's (usually my own). So I got a lot
> of experience being an API designer as well as an API consumer all at the
> same time.
>
> -c
>
> From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On
> Behalf Of Chris Brandsma
> Sent: Monday, April 21, 2008 11:04 AM
> To: altdotnet@yahoogroups.com
> Subject: Re: [altdotnet] Why TypeMock for TDD?
>
> Some of it will come down to design decisions for your production code.
> I also love Rhino Mocks (Moq is cool, but I haven't gone there yet), but I
> have come to change my coding style a bit to suit its idiosyncrasies.
>
> If you are going to stick with Rhino Mocks, here are the design decisions
> you are basically stuck with:
>
> * Static classes/methods are evil and must be stopped
> * IoC is your only friend
> * If the method isn't public it is hiding something that is vitally
> important to national security. Interrogate repeatedly.
> * All smart methods are abstract. Others, obviously, descend from unworthy
> ancestry.
>
> If your code fails this litmus test, then you might want to think about
> TypeMock.
>
> On Mon, Apr 21, 2008 at 9:49 AM, Casey Charlton <casey@...>
> wrote:
> So far ... only from trial use a while back ...
>
> TypeMock does everything Rhino does, with a slightly nicer syntax ... it
> can also mock sealed/internal/class use with no interfaces ...
>
> If you want nicer syntax, Moq may be better... or Oren just did a 3.5 Rhino
> with yet another syntax ...
>
> SO the only place I know where TypeMockwins hands down, it is in mocking
> legacy stuff ... my last project with Sharepoint Typemock would have been a
> god send ... but price beat it out the door with a big stick.
>
> But I have taken Roy up too ... I'll try it out and see how it goes ...
>
>
> I think a lot of mock framework useage is just what you feel comfortable
> with
>
>
> On 21/04/2008, Chad Myers <chad@...> wrote:
> What if I like my design style w/r/t interfaces?
>
> I was using interfaces before I know about Rhino mocks and testing was a
> pain and I actually stumbled into Rhino Mocks because I had that
> particular pain and Rhino fit (as would Moq, too probably).
>
> TypeMock can do it, for sure, from what I understand, but I'm
> specifically interested in any extra features it might have w/r/t TDD
> and mockist-style interaction testing.
>
> Let me try the question this way: I'm actually pretty happy with Rhino
> Mocks. I have problems with mockist interaction-based testing that are
> deeper than which mocking framework I use (yes, Greg Young/Scott
> Bellware, I know... I know...), but when I'm doing mockist interaction
> testing, Rhino works pretty well for me.
>
> But I don't want to be a curmudgeon. If I'm missing something totally
> awesome in TypeMock that it will make my mockist interaction stuff go
> faster, I'd really like to know what those features are!
>
> Thanks,
> Chad
>
> P.S.- Colin Jack, this is NOT an invitation to start another mockist vs.
> classicist debate :)
>
> -----Original Message-----
> From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On
> Behalf Of Ben Hall
> Sent: Monday, April 21, 2008 10:26 AM
> To: altdotnet@yahoogroups.com
> Subject: Re: [altdotnet] Why TypeMock for TDD?
>
> Because the test you are about to write deals with a legancy code base
> with no interfaces and objects which can't be mocked with Rhino or Moq
> - as a result, TypeMock becomes your friend.
>
> For a brand new system, I feel It does allow you to have more control
> over your design, you don't need to add an interface to everything you
> are going to mock and you can mock certain objects more easily. You
> have the flexiblity available for when you hit those issues. Just
> depends if your going to hit those issues....
>
> On Mon, Apr 21, 2008 at 4:09 PM, Casey Charlton <casey@...>
> wrote:
> >
> >
> >
> >
> > Apart from that I'm sure it is great :)
> >
> >
> > On 21/04/2008, Chad Myers <chad@...> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > So I was thinking about taking Roy up on his TypeMock offer, but I
> didn't
> > want to go into it blind and dumb with no context.
> > >
> > >
> > >
> > > It is my sincere intention that this NOT turn into a debate right
> off the
> > bat. I've heard all the reasons (I think) why NOT to use TypeMock for
> new
> > Greenfield development using TDD. I would like to hear a few WHY's at
> > least.
> > >
> > >
> > >
> > > Rules:
> > >
> > > - The first few replies can't be Roy (this is to protect
> you Roy
> > - love you man)
> > >
> > > - Dissenting opinions and debate should be held until after
> at
> > least a few solid replies. Debate is OK, but I want to hear the
> assenting
> > side clearly first.
> > >
> > > - Two men enter, one... nevermind, different context.
> > >
> > >
> > >
> > > Kickoff:
> > >
> > >
> > >
> > > So, I just got hired by XYZ corp, we're doing TDD. I'm sitting at a
> pair
> > station with my pair and TypeMock and everything else is installed and
> I'm
> > going to write my first test that will involve mocking. Why should I
> start
> > with TypeMock instead of (something else)?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Chad
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> --
> --------------------------------
> Christopher Brandsma
> http://www.ChrisBrandsma.com
> http://www.ElegantCode.com
>
>



--
Studying for the Turing test