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

Ummm.. it's not the same effect. My alternative implementation is REALLY
used by the application (for example, in the weekly iteration deliverable),
so no fixed return_value to set via mock magic. I'm using it (the
alternative implementation) as an implementation that cover all the use
cases (no more, no less). And, in general, it is created using TDD itself.


On Wed, Jan 22, 2014 at 10:55 AM, Mateusz Łoskot <[email protected]> wrote:

>
>
>
> On 17 January 2014 10:25, Angel Java Lopez <[email protected]> wrote:
>
>>
>> Interesting thread!
>>
>> Regarding
>> def exists(item_id):
>>     xdep.open()  # opens some remote resource
>>
>>     item = xdep.get_item(item_id)
>>     xdep.close()
>>     if item:
>>         return item.id == item_id
>>     else:
>>         return false
>>
>> I usually write a xdep alternative implementation. I don't call it a
>> mock, because is an implementation of the same service, but local. And I
>> use it even in the final application (for first iteration, for demo
>> purpose). You can build it using TDD, and then, inject it to the exists()
>> test. It has no additional method like "expected" nor other mockist methods.
>>
>
> It makes sense to me, but if we forget Python's module name of
> unittest.mock uses word 'mock',
> then the only difference at low level of how xdep double is implemented:
> - you would write by hand an alternative implementation of xdep
> - I use Mock class to automate things
>
> # mock will generate implementation for me
> self.xdep = mock.Mock()
> # I ask the object of Mock class to 'implement get_item for me so it
> returns 1'
> self.xdep.get_item.return_value = 1
>
> but net result (and effect) is the same, I believe.
>
> The details how the 'magic' happens, let someone write by hand or let
> something generate it, are IMO not important for my question
> which Roy has nicely captured in
>
> "I would use a STUB for a get_something if not faking it meant an
> integration test"
>
> How the get_something is faked, that is a different kind of issue.
>
>
> Best regards,
> --
> Mateusz  Łoskot, http://mateusz.loskot.net
>
>  
>