1

Recently, I've been reading a lot of articles (mostly from J.B. Rainsberger) about contract and collaborative tests. In order to get it into it, I've started a small project.

From my understanding, the responsiblity of a contract test is to ensure that an implementation respects its interface inherent contract. In other words, it encourages the Liskov substitution principle.

Mocking an objects collaborator is, basically, all about making assumptions about it. Now, what happens if these assumptions change? If I mock the collaborator using Mockito like this (which comes to the same thing as stubbing):

 when(collaborator.doSomething(someArgument)).thenReturn(someValue);

I won't be able to notice the changes when I'll modify the collaborators interface (that is, its contract).

So here's my question : Is it right that when faking a collaborator which provides indirect inputs to a system under test, one should use stubs in order to prevent unnoticed interface / contract changes?

Here are some links that I've already checked:

removing-the-integration-test-scam-understanding-collaboration-and-contract

writing contract tests in java differently

I hope I'm clear enough, if not, I'll do my best to make this more transparent. Thanks to you all in advance.

Community
  • 1
  • 1
Francis Toth
  • 1,595
  • 1
  • 11
  • 23
  • I believe this is more suited for Programmers than for SO - read their [faq](http://programmers.stackexchange.com/faq). – poplitea Dec 03 '12 at 22:09

2 Answers2

0

there is a clear separation between Stubs and Mocks.

A stub is a stand-in and cannot change the outcome of the test. For example, an input parameter that is passed into the subject.

A mock on the other hand can fail a test. It is the basis for the testing the collaboration between objects. If the expected collaboration is not met, the test should fail.

So in the context of your question, indirect inputs into a system should be stubs.

bryanbcook
  • 16,210
  • 2
  • 40
  • 69
  • As necessary it is to explain the difference between mocks and stubs, it only answers the question partially. 1) the mocks vs stubs problem is orthogonal to dealing with contract changes, mocks and stubs will detect the same contract modifications at compile time and 2) more subtle contract changes won't be detected by them anyway, so you have to have some other kind of strategy to deal with them. – guillaume31 Dec 04 '12 at 14:40
0

JB Rainsberger has an article that seems to precisely answer your question : Who Tests The Contract Tests ?

So here's my question : Is it right that when faking a collaborator which provides indirect inputs to a system under test, one should use stubs in order to prevent unnoticed interface / contract changes?

Use stubs as opposed to what ?

Mocks ? That doesn't make a big difference, and stubs are more appropriate in that kind of situation anyway, as pointed out by @bryanbcook .

Manual fake classes that don't even implement the same base class as the collaborator ? Sure.

IMO there are 2 kinds of contract changes :

  • "Hard" changes, i.e. changes in the return type or parameter types of your collaborator's method. These modifications are easy - they can't go unnoticed as your tests won't even compile any more, provided your fake collaborator implements the same interface/base class as the real collaborator.

  • "Soft" changes, i.e. changes in the conditions under which the collaborator returns a given value or another, changes in the range of values the collaborator can return or accept, in the exceptions that could be thrown, etc. These are more difficult to spot but according to the aforementioned article, they could be avoided by enforcing a strict correspondence between contract tests and collaboration tests.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • Very interesting comment. I've just read a similar one on which JB Rainsberger agrees. Basically, if you're rigorous enough, there shouldn't be a need to stub every indirect input, it's a matter of balance. Thanks. – Francis Toth Dec 04 '12 at 16:35