Comments on Mock Objects: "Stop Designing for Testability"

@Anonymous

I think you're missing the point...

2008-10-21T15:51:00.000+01:00

@Anonymous

I think you're missing the point here. With DI, the intention is that the called code should not be making decisions about the implementation of significant neighbouring objects. It should focus on doing one thing well, otherwise it starts to cross domains and loses coherence. I've seen so much lucky-dip code like this that has to be taken apart to be reused.

In your example, the Business Object should just receive an appropriate DAO. Any details about file systems or databases are not a matter of the logic of the business.

It looks like you've been following the material from TypeMock. We simply disagree with their view for new code. We've been doing this for many years now, generally with good results.

Next time, please consider signing your posting.

Dependency Injection means that you instansiate th...

2008-10-20T16:17:00.000+01:00

Dependency Injection means that you instansiate the object in the calling code and pass it to the code that needs it. This means two things..

1) The calling code needs to know how to instanciate the dependancy and this may involve intricate business logic.

2) The called code cannot make decisions about what object to use as it's simply passed in.

An example is a Biz object calling a DAO. The DAO will most likley create a connection object and a command object. The specifics of these objects may be based on the availability of a persistent storage device (if the database is not available use the local file system). This decision affects both the command and the connection object. With the DI pattern, all four objects will need to be created and passed in whether they are needed or not!

It is simply not correct to have to instansite all these objects simply to be able to prevent the called code from accessing the physical layer below when all we need to do is ensure that the method is called.

If you want to be forced to write good code then use FX Cop - that's what it's for. A Mocking Framework is designed to test your code not force you to write somebody elses code.

As we keep saying, we don't expose internals, we m...

2007-12-03T22:04:00.000Z

As we keep saying, we don't expose internals, we make dependencies explicit.We also find that taking testability into account pushes us towards what we think (IOHO) are better OO designs. Your mileage (whoever you are) may vary.

exposing the implementation internals of a class t...

2007-12-03T21:25:00.000Z

exposing the implementation internals of a class to consumers is BROKEN OOD.

I don't care that the reason is to enable "testability."

Simple as that.

Thanks for commenting. I'd be curious to see what ...

2007-05-06T10:42:00.000+01:00

Thanks for commenting. I'd be curious to see what your domain objects look like, whether it would be simpler just to use the real thing. It would be great if you could send me or post some examples.

On the counter side, I've been working with a team who have some reasonably convoluted domain code. We could have shortcut the process with something like TypeMock, but (to me) the result of breaking things up with interfaces has produced a much clearer design.

It looks like we really needed an extended bake-out, rather than both sides asserting their experience :)

This is atopic I find fascinating. I've kind of gi...

2007-05-05T23:43:00.000+01:00

This is atopic I find fascinating. I've kind of given up on designing for testability as I found it complicated my designs in ways that weren't helpful.

So although I agree with this...

Reaching in to an object and manipulating its internals ties the test to the implementation and makes it brittle—which is the usual objection made against interaction testing

..I have also found that TypeMock is useful. We quite often want to mock out domain classes (e.g. Customer/Order). I don't want to implement interfaces or include virtual methods in them just to allow mocking and in those cases I find TypeMock really helps.

Oops. Apologies and corrections.

I guess I ...

2007-03-02T11:38:00.000Z

Oops. Apologies and corrections.

I guess I should also say that I was just teasing about the "legacy languages" bit. My favourite languages are older still.

Thanks for the support, but one small clarificatio...

2007-03-02T10:50:00.000Z

Thanks for the support, but one small clarification: I'm not the developer of RhinoMocks - that would be Oren Eini (Ayende.com).

Cheers!

Roy Osherove
www.ISerializable.com