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

On 15 January 2014 04:41, Adam Sroka <[email protected]> wrote:

> 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.
>

Yes, that is waht a general theory of (unit) testing says, but...devil's in
the detail like
classicists vs mockists (
http://martinfowler.com/articles/mocksArentStubs.html)
I mean, lots of things about unit teststing makes a perfect common sense
and is obvious... from high altitude,
but practice seems to be much more complex.



>
>>  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.)
>

I believe that the fake xdep.get_item() from my example is a direct
collaborator, isn't it?
(let's ignore the fact get_item() is Python free function, not an object of
class, it is irrelevant for this discussion).

In my example, I think I don't do anything different than Roy Osherove [1]
in faking his ILogger as mockLog object and
veryfying mockLog.Expect("Write", "ya|"), am I?

[1] http://youtu.be/fAb_OnooCsQ?t=32m33s

  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.
>


Right, that is a very good question to remember/consider.

 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.
>

Yes, sounds sensible, if not obvious.

Best regards,
-- 
Mateusz  Łoskot, http://mateusz.loskot.net