Comments on dave^2 = -1: An example of driving design through top-down test...

Hi Mike, Hope this managed to go part way towards...

2009-09-02T10:12:18.036+10:00

Hi Mike,

Hope this managed to go part way towards answer some of the questions you raised last post.

My take on mocking frameworks is to not use them until it is blindingly obvious you need one (this implies you've looked at them and have an idea of what they do). This means hand-writing all your mocks/stubs for tests until you get so sick of it you are forced to use a framework. :)

Going through this process will automatically answer the when/when not to use them question. I found it invaluable.

And your description of how stubbing a method call works is perfect. :)

Why didn't I mock report data? Completely arbitrary decision. You definitely could mock it, and it might be a better decision to do so because then you can change how that class works without breaking tests.

For this case the Results class is a dumb Data Transfer Object (DTO). It has no behaviour of its own, it is simply holding data. By not mocking it I've pretty much committed to keeping it as such. Mocking would give me more ability to change this.

In retrospect this was an unfortunate decision for an explanatory blog post as it unnecessarily confuses things. Sorry. :-\

You are also right about the purpose of mocking being isolation of the sut from its dependencies. It's definitely not the intention to go and replace the mocks/stubs used in tests with real versions.

In terms of the "Aha!" moment for mocking, I think the first step is to work on basic dependency injection first (not DI containers, just plain old constructor injection), and manually code the fake versions of these for tests. The progression to a mocking framework will start to happen naturally from there.

Regards,
David

Great post! Thanks, it was very helpful to go thr...

2009-09-02T06:06:12.812+10:00

Great post! Thanks, it was very helpful to go through that same mental process that you guys went through. I realize this wasn't a representation of everything there is to know about testing and design, but it seems that if you follow these guidelines, you're in for some simple, organized, and maintainable code that you can feel confident about.

I do want to ask a follow up question or two, however. I understand the need for mocking frameworks, but I've never used them yet. It would be helpful if you could briefly describe your take on the role and need such frameworks fill when testing and when to use them and when not to. Also, just to make sure I understand, when a mocking framework stubs a method call, it creates some fake, relatively empty implementation of that method and it's return value (which you can also configure to be whatever you want), correct?

As for this example, we used a mock for an unimplemented IIntegerArrayDataSerialiser. I think that makes sense, in that we can continue with our current SUT and not get unnecessarily sidelined at the current moment with one of it's dependencies. But why didn't we mock getting the report data as well? This is the part I am the most confused about. I'm sure we won't go back through our tests and remove mocking stubs once implementations are created for dependencies, so that can't be the one big compelling reason for mocking. The whole point is to test things in isolation from their dependencies, correct?

I don't think I'm mixed up, but I just haven't had the "Aha!" moment regarding mocking yet. Thanks in advance for any guidance or explanation you can provide.