On Tue, Jan 14, 2014 at 5:31 PM, Mateusz ?oskot <mateusz@...> 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.?
