Re: Re: Single assert / Single mock rule in practice

On Tue, Jan 14, 2014 at 5:31 PM, Mateusz Łoskot <[email protected]> wrote:

>
>
> Isn't a unit test somewhat tightly coupled to implementation?
>
>
Yes, by definition, because you are testing the way the "unit" works. It is
necessarily coupled to the interface of the object you are testing, though
not necessarily to its internals. If the test is coupled to the internals
of the object that is a failure of encapsulation and there is probably a
detectable code smell.



> Isn't the fact that I create a mock for a dependency used deep in
> implementation of method/behaviour under test, isn't it exposing
> implementation details, hence coupling the test and increasing risk
> of reimplementing test if the method/behaviour under test changes?
>
>
If you use a test double it should be for a direct collaborator and verify
that the object under test communicates with that collaborator according to
its interface contract. If you are doubling things that aren't direct
collaborators that is another design smell (see Law of Demeter.)

 As for the last part, if the behavior changes and the test doesn't have to
change I would wonder if it was really testing anything. A good microtest
tests one permutation of one behavior of one object. If that behavior
changes the test should break. Only if the structure changes but the
behavior remains the same (which is the canonical definition of
refactoring) should the test not break.