The Flawed Theory Behind Unit Testing, Michael Feathers

[Luca Minudel]

Hi,

this article

- The Flawed Theory Behind Unit Testing, Michael Feathers
  http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html

as I understood it state 3 assumptions:

1- unit tests in the GOOS style are really unit and test each object in isolation
2- make a use of mock objects more frequent than other unit testing styles
3- does not necessarily include the use of integration tests


As I understood and learned the technique from one of the guys working at Connextra when was invented, and as I noticed in practice, the assumption 3 seems not correct to me: integrations and/or acceptance tests are a required companion to the GOOS unit tests to spot integrations bugs and out-of-date mocks.


As I learned reflecting and reading from this list, about the point 2, the other relevant point is that the mocks should be strict because that put the focus on the communication protocol between objects (as opposed to spies).



Is this correct ?


Luca

[Steve Freeman]

On 28 Sep 2012, at 14:35, Luca Minudel wrote:
> as I understood it state 3 assumptions:
>
> 1- unit tests in the GOOS style are really unit and test each object in
> isolation
> 2- make a use of mock objects more frequent than other unit testing styles
> 3- does not necessarily include the use of integration tests
>
> As I understood and learned the technique from one of the guys working at
> Connextra when was invented, and as I noticed in practice, the assumption 3
> seems not correct to me: integrations and/or acceptance tests are a
> required companion to the GOOS unit tests to spot integrations bugs and
> out-of-date mocks.
>
> As I learned reflecting and reading from this list, about the point 2, the
> other relevant point is that the mocks should be strict because that put
> the focus on the communication protocol between objects (as opposed to
> spies).
>
> Is this correct ?

yes (for me)

the point about strict mocks is more complicated, because I care about interactions, rather than entire objects. I might allow one method on an object but expect another in an individual test. That said, usually I don't want arbitrary unchecked behaviour happening within the scope of a unit test. I want to know if something has changed.

S.

[Luca Minudel]

Hi Steve,

you wrote:

> I might allow one method on an object but expect another in an individual test.

can you please make an example where you allow one method and at the same time you expect another method of the same object, in an object that adhere to the SRP ? I could not come up with a good one.

Luca

[Uberto Barbini]

I think he's talking about allow, expect in a strick JMock sense. That
is having some method calls optional (usually read/getters I assume).

Uberto

[Luca Minudel]

Ok, that make sense to me.

For what I can remember when I had to allow a method (that if it is called zero, one or more times it is always ok to have a green test) and expect another method on the same object, that object had some design problem (usually a SRP violation).

That's why I.m interesting to see an example like that, not caused by a design problem.

Luca

[Colin Vipurs]

If you're using any kind of Repository or CRUD interface you might
well be allowing() calls to read data but only expected oneOf() a call
to persist the data back again.

What I typically see more of is just a single test that does a oneOf()
on an object and all other tests that interact with that object use
allowing().

--
Maybe she awoke to see the roommate's boyfriend swinging from the
chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

[Uberto Barbini]

Generally speaking when I found myself writing several allowing() on a
object I smell a potential birth of a new ValueObject, either by a
conversion Entity->ValueObject or via a split Entity -> Entity + VO.
Of course your mileage may vary.

cheers

Uberto

[Colin Vipurs]

Do you mean several allowing()s in one test method or in a test suite?

[David Peterson]

I sometimes use allowing() to down-play method calls that are not pertinent to the behaviour I'm trying to show in the test, even if those method calls are required.

[Uberto Barbini]

Everywhere I'm mocking that object.

For example I have my Entity called AdvertisingSpace

I mock AS everywhere I need it to test its collaborators (say
Publisher and Impression).
Let's say I discover myself to write something like that:

allowing(advertisingSpace.getChannel())
allowing(advertisingSpace.getSize())
allowing(advertisingSpace.getPlatform())

because some collaborators need only some of the informations in
different moment.

What I mean is to create a new VO AdvertisingSpaceAttributes with all
the attributes and a call advertisingSpace.getAttributes() which
return it.
Or still better Hollywood style methods on the collaborators which receive it.
This call will be expected in the mocks in all tests.


cheers

Uberto

[Colin Vipurs]

One of the things I like about this approach is that it becomes very
easy to spot this is going on and push you towards a design change

[Steve Freeman]

Good question. And I think you're probably right (except for containing objects where you get it out and put it back again). Others have said anything I would have. 

S. 

Steve Freeman

http://www.higherorderlogic.com

Written on a phone, so please allow for typos and short content.