[ACCEPTED]-Should I practice "mockist" or "classical" TDD?-mocking

Accepted answer
Score: 43

I don't think you need to choose one over 18 the other. Both have their advantages and 17 disadvantages and both are tools for your 16 toolbox. "Mockist" tdd makes you a bit more 15 flexible in what you can test while classical 14 TDD makes your tests a bit less brittle 13 because they tend to look more at the input/vs 12 output instead of looking at the actual 11 implementation. When doing mockist unit 10 testing I seem to have more tests break 9 when changing the implementation.

I try to 8 use classical tdd whenever possible (although 7 i often use a mocking framework to set up 6 the stubs quickly). Sometimes I notice I 5 start testing too much at one time or i 4 need too many objects to set up a test. That's 3 when mockist testing can often help you 2 set up smaller tests.

This is all quite abstract 1 so I hope i make sense

Score: 29

The question about mockist or classic tdd 18 is very much about what part of your application 17 you're testing. If you have a "standard" layered 16 architecture (like DDD for example) the domain 15 layer is usually suited for classic tdd 14 where you unit test by setting up the object 13 under test, call a few methods and check 12 the result and/or the state.

On the otherhand 11 when you're testing application services, controllers 10 or presentation logic which all do more 9 coordinating work, mocking or stubbing is 8 often needed to get good tests. My experience 7 is also that these classes tend to call 6 other layers (webservice, datalayer,...) which 5 you really want to mock or stub. These unit 4 tests also need more setup code so you should 3 only mock when you have to.

My advice is 2 to go classic whenever you can and mock 1 when you must.

Score: 17

You might consider looking at our book, at 5 http://www.growing-object-oriented-software.com/. It includes an extended worked example. As 4 we wrote it we discovered that the state 3 vs. interaction distinction is largely misleading 2 and it's more about one's approach to OO 1 design.

Score: 8

A very pragmatic approach was exposed by 10 Sandi Metz:

An object can communicate to 9 other object through outgoing or incoming 8 messages. The messages can be queries (returns 7 something) or commands (executes something).

There 6 are four combinations. The outgoing query 5 messages not should be tested (already tested 4 as incoming query of external class) You 3 could to use the mockist test method on 2 outgoing command messages and classical 1 test to the rest.

enter image description here

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

Youtube

Score: 2

I am still relatively new at TDD - but the 18 way I was taught/introduced to the differences 17 was to think of it in terms of testing the 16 integration between classes and so that 15 you are not dependent on live data. For 14 instance if I have a class that is pretty 13 much stand-alone - not dependent on other 12 classes I have built for a project and it 11 doesn't go out to a live data/dev environment 10 for input (like a DB or an API to a system) then 9 I would only use classical unit tests in 8 something like NUnit or JUnit - but when 7 I start to test interaction between built 6 classes - that's when it can get real handy 5 to mock other custom classes and/or outside 4 interaction - so that you can single out 3 and test your current classes' code without 2 trying to chase down a a potential bug in 1 other classes you are calling.

More Related questions