Unit Testing pattern -

i looking solution/pattern following unit testing case.

the case:

let's pretend have 3 classes, a,b,c each 1 method. a's method calls b's method calls c's method. so, a->b->c. each method take 1 input (input method a, input b, input c). resulting output of call method a, tree structure such as:

root (created method a) -- node b (created method b) -- node c1 -- node c2 (both created method c)

for me unit testing testing output input of method in isolation. so, write unit tests each of methods above. because tests written in isolation, mock method b when writing unit tests method a, , mock method c when writing unit test cases method b.

so far, good, can write expectations on output each method make sure resulting tree structure respected.

the problem:

let's add class call method b have following call chain: d->b->c. resulting root tree this:

• root d
  • node b
    • node c1
    • node c2

during development, realise requirement method misunderstood , tree result should have looked this:

• root
  • node b
    • node c

happily developer change method c output returns 1 node rather two. change unit tests reflects changes. however, method d requirements should not have changed, , output of method should still have node c1 , node c2.

the question:

how have written unit tests second developer have been alerted of breaking change have introduced method d? rather avoid integration tests seem best fit here.

thanks.

if want stick isolated unit tests (which of central objects since find impossible write right amount of integrated tests right depth , keep them fast), interesting approach joe rainsberger's contract , collaboration tests. raises point shouldn't mock out dependency behave way in test unless have corresponding contract tests ensuring concrete implementations of dependency behave way in real world.

in example, saying "method c returns 1 node rather two" means changing c's contract , contract tests accordingly. introduces possibility mocked c become out of sync new contract, therefore should in tests everywhere c mocked , adjust mocks if need be.

which after careful examination of existing tests lead realize don't want change contract method c rather introduce new method c2 suits needs of a.

rainsberger describes process uses make sure he's got reciprocity in tests here. can watch technique in action in this video.