I've read (and re-read) Martin Fowler's Mocks Aren't Stubs. In it, he defines two different approaches to TDD: "Classical" and "Mockist". He attempts to answer the question "So should I be a classicist or a mockist?", but he admits that he has never tried mockist TDD on "anything more than toys." So I thought I'd ask the question here. Good answers may repeat Fowler's arguments (but hopefully more clearly) or add arguments that he didn't think of or that others have come up with since Fowler last updated the essay back in January 2007.
Asked
Active
Viewed 9,788 times
5 Answers
47
I don't think you need to choose one over the other. Both have their advantages and disadvantages and both are tools for your toolbox. "Mockist" tdd makes you a bit more flexible in what you can test while classical TDD makes your tests a bit less brittle because they tend to look more at the input/vs output instead of looking at the actual implementation. When doing mockist unit testing I seem to have more tests break when changing the implementation.
I try to use classical tdd whenever possible (although i often use a mocking framework to set up the stubs quickly). Sometimes I notice I start testing too much at one time or i need too many objects to set up a test. That's when mockist testing can often help you set up smaller tests.
This is all quite abstract so I hope i make sense
Mendelt
- 36,795
- 6
- 74
- 97
-
Hello. It's been a while since your answer, but I'm struggling to learn how you actually do classical TDD. If I have a `UserService` with a `signUpUser` method, there are dependencies on password hashing, data validation, email sending, repository, etc. Does Classical TDD say to create "fakes" (not mocks) for all of those deps or to use the real ones where possible? Of course, you'd have to fake the Email Service and Repository. If that's the case, is it still a "unit" test? Thanks. – Feb 09 '20 at 08:25
-
Hi Jamie, from your description I think "traditional" tdd is just not the right tool for you to use in that situation. Traditional tdd works very well when you're testing isolated functions. But the code you're describing sounds like it's orchestrating operations on several dependencies. There mockist tdd sounds like the right tool for the job. – Mendelt Feb 17 '20 at 14:29
31
The question about mockist or classic tdd is very much about what part of your application you're testing. If you have a "standard" layered architecture (like DDD for example) the domain layer is usually suited for classic tdd where you unit test by setting up the object under test, call a few methods and check the result and/or the state.
On the otherhand when you're testing application services, controllers or presentation logic which all do more coordinating work, mocking or stubbing is often needed to get good tests. My experience is also that these classes tend to call other layers (webservice, datalayer,...) which you really want to mock or stub. These unit tests also need more setup code so you should only mock when you have to.
My advice is to go classic whenever you can and mock when you must.
-
-
2I would say so. The frameworks have changed but I still unit test pretty much the same way. – Dala Feb 09 '18 at 13:51
-
Most types of refactoring you'd want to do involves moving logic between modules - something which breaks mockist-style tests, rendering them useless at helping you refactor safely. For this reason, I'd much prefer classic-style (similar to this answer), but I'll still occasionally use mockist-style when the need arises (e.g. classic tests can't reach where I want to test) – Scotty Jamison Aug 03 '22 at 14:13
18
You might consider looking at our book, at http://www.growing-object-oriented-software.com/. It includes an extended worked example. As we wrote it we discovered that the state vs. interaction distinction is largely misleading and it's more about one's approach to OO design.
Steve Freeman
- 2,707
- 19
- 14
-
6Steve, I read the book, but I missed or forgot the part about state vs interaction being misleading. Is this topic addressed directly in the book or is it an ambient theme that shines throughout the content? Can you point me to the chapter or section in the book where I can find it addressed? – Grzesiek Galezowski Mar 12 '13 at 10:14
8
A very pragmatic approach was exposed by Sandi Metz:
An object can communicate to other object through outgoing or incoming messages. The messages can be queries (returns something) or commands (executes something).
There are four combinations. The outgoing query messages not should be tested (already tested as incoming query of external class) You could to use the mockist test method on outgoing command messages and classical test to the rest.
Check the links
http://jnoconor.github.io/blog/2013/10/07/the-magic-tricks-of-testing-by-sandi-metz/
https://speakerdeck.com/skmetz/magic-tricks-of-testing-ancientcityruby
2
I am still relatively new at TDD - but the way I was taught/introduced to the differences was to think of it in terms of testing the integration between classes and so that you are not dependent on live data. For instance if I have a class that is pretty much stand-alone - not dependent on other classes I have built for a project and it doesn't go out to a live data/dev environment for input (like a DB or an API to a system) then I would only use classical unit tests in something like NUnit or JUnit - but when I start to test interaction between built classes - that's when it can get real handy to mock other custom classes and/or outside interaction - so that you can single out and test your current classes' code without trying to chase down a a potential bug in other classes you are calling.
silverbugg
- 214
- 2
- 7