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

Unit tests _are_ about implementation at a certain level, and about
interface at another.

The difference is that we are talking about the "interface" of a class,
which may be buried deep in the application. So that interface is part of
the implementation of the next level up. What might be considered an
"internal" for one test is then part of the interface for another test.

So unit tests (or, as I now prefer, micro-tests) are around implementation,
but not around the implementation of the precise thing you are testing.
Unit tests, after all, test that the intent of the programmer is satisfied
and the intent of the programmer has a lot to do with internals.

Charlie


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

>
>
> On 14 January 2014 16:31, Avi Kessner <[email protected]> wrote:
>
>>
>>
>> "I could have replaced
>> self.assertTrue(item_exists)
>> with
>> foo.xdep.get_item.assert_called_once_with(1)"
>>
>> These two things are not equivalent tests.
>>
>
> Yes, I've come up to this conclusion after some time.
>
>
>> your first assert, is correct and is testing the interface.  You expect
>> the item to exist if get_item returns the value of 1.
>> Your second assertion is testing the implementation.
>>
>
>
> Indeed, and that is a matter of my concern.
> I'm testing the implementation and somewhat implicitly I'm assuming this
> particular test
> verifies the foo.exists() - as the foo.exists() is implemented in such way
> that if get_item returns
> id equal to the id that is being tested.
>
> Yes, I agree it is an unfortunate test, or it is a different test, hence
> my questions.
>
>
> What if you later change the get_item function to return an object instead
>> of the item id?  Do you really want to re-write this test?
>>
>
>
> Yes, I will have to re-write the test and as far as I understand it is
> nothing uncommon.
> I admit, this also confuses me a bit.
>
> Isn't a unit test somewhat tightly coupled to implementation?
>
> 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?
>
> AFAIU, this risk is included in price of unit tests, low level tests,
> isn't it?
>
>  Best regards,
> --
> Mateusz  Łoskot, http://mateusz.loskot.net
>
>  
>