Comments on: Shifting testing strategies away from mocks

By: jrnail23

jrnail23 — Tue, 18 Jan 2011 00:12:10 +0000

Hi Jimmy,
I’ve asked some of these same questions myself, and I think it might come down to setting up some sort of mechanism in your testing architecture that can swap out a fake/mock/stub with the real implementation (likely via IoC container) according to some test category/attribute, but keeping the same test logic. I haven’t really chased it much myself, but it seems like it might be worth the effort.

Also, with respect to BDD, I gave it a good try a couple months back, but I kept getting frustrated with the tooling (specifically that the libraries I tried either involved too much setup effort, or they never seemed to match my abstract abstract mental model for what I was trying to accomplish).

That said, there also didn’t seem to be a lot of practical guidance out there for successfully applying BDD.

By: Nick

Nick — Fri, 14 Jan 2011 13:39:20 +0000

@Paul

I think in your case the answer may be in his post. If you are testing that a method has been called, it is a barrier to refactoring if you wanted to break that method down into two etc.

By: Confused

Confused — Thu, 13 Jan 2011 17:22:50 +0000

I think a simple example is in order here. Something that demonstrates the process that you go through using “Integration tests that go end-to-end as the first test I write, and usually the last test that passes” as a theme.

Thanks in advance.

By: Paul Cowan

Paul Cowan — Thu, 13 Jan 2011 15:26:51 +0000

Where I agree over mocking makes tests pointless, I am still struggling to see how you test that a void method was called.

I use doubles a lot but I don’t want to create extra classes just to return fake data.

I might be missing the point also

By: James Morcom

James Morcom — Wed, 12 Jan 2011 19:31:59 +0000

Using the collection-backed repository as an example, could you explain how that overcomes the problem of exposing implementation?

I ask because in my mind that collection-backed repository is essentially doing the same thing as a mock/stub, except you’ve spent more time implementing it.

Sure the repository class is usually situated somewhere other than the unit tests so you’re less aware of it, but you could just as easily do the same with fakes I think?

I still feel like I’m missing the point

By: bogardj

bogardj — Wed, 12 Jan 2011 14:26:55 +0000

@Paul

Fakes/stubs for things I can’t control/or are slow (DB, web service etc.). i.e., using an in-memory DB or collection-backed repositories, for example.

Integration tests that go end-to-end as the first test I write, and usually the last test that passes.

By: James Morcom

James Morcom — Wed, 12 Jan 2011 14:01:59 +0000

@Paul Cowan I think he’s saying that you should “bootstrap” all the services you need before running the test. i.e. Set it up to use a real database (be it SQLite or whatever), like you would with an integration test.

I’ll be intrigued (in a good way!) if that’s not the case

By: Paul Cowan

Paul Cowan — Wed, 12 Jan 2011 13:27:40 +0000

So are you saying you supply hand rolled fakes, stubs or doubles?

By: Nick

Nick — Wed, 12 Jan 2011 09:50:53 +0000

Interesting comments and a good point of reference for anyone experiencing the problems you mention.

I have this feeling this isn’t a post that will inspire the TDD purists.

A few examples would be nice, Jimmy.

By: John V. Petersen

John V. Petersen — Wed, 12 Jan 2011 02:44:24 +0000

Absolutely agree 100% here. And when going to a BDD style of testing wherein you have a fixture per system under test, A – your tests are more readable (aka a spec) and B – less likely to have side effects. I’ve started to look at m-spec – but I’m not a big fan of it. Quite frankly, it is easy to roll your own framework.

Nice post Jimmy!!