¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Single Messages Topics Expanded Polls

Re: [TDD] Re: Single assert / Single mock rule in practice

Mateusz ?oskot
 


On 15 January 2014 20:08, Adam Sroka <adam.sroka@...> wrote:
On Wed, Jan 15, 2014 at 12:56 PM, Mateusz ?oskot <mateusz@...> wrote:
On 15 January 2014 04:41, Adam Sroka <adam.sroka@...> wrote:
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.?

Yes, that is waht a general theory of (unit) testing says, but...devil's in the detail like
classicists vs mockists ()
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.



It gets easier over time if you practice merciless refactoring. The problem is that most programmers don't. They change stuff when it is obvious and makes their lives immediately easier and defer it otherwise. Then it turns into a mess and they no longer know how to fix it easily.?
[...]

Adam,

I see your point, although it does not mean I immediately see where to plug it in my practice.
?
When and whether to use mocks is more a matter of style than anything else, and philosophical debates about it are mostly a waste of time.?


I do not mean to start any such debate, no.

I am learning from many resources what you are saying, when/if to mock is matter of style and I have no reason to not to trust it is.

But, as soon as I get back to practising UT
and I have an external dependency, i.e. remote service, mocking an obvious choice
otherwise I can't see how I can continue testing my unit without either integrating
with real remote service or mocking it.
Then I remember "mocking is matter of style" and I get confused immediately:
does it mean I either test my unit with mocking or not test at all?

I hope you can trace the tracks of my thinking here.

The a self-contained complete example I posted in which I'm
trying to test xdep as external legacy, uses code
beyond my control. I can't change how xdep is designed.

Let's try to simply it to get away from conceptual discussion on?
techniques and methods, and get down to bare code:

def exists(item_id):
? ? xdep.open() ?# opens some remote resource
? ? item = xdep.get_item(item_id)
? ? xdep.close()
? ? if item:
? ? ? ? return??== item_id
? ? else:
? ? ? ? return false

Given id of an existing item,?
When I call exists()
Then it reports item does exists (return True)

How would you test such function?

1. Mock the whole xdep (and set up all 3 functions as necessary for the scenario above).
2. Pick most relevant xdep function, namely the xdep.get_item and mock it?
3. No mocking at all? Then, how would you unit test exists function?

Best regards,
--
Mateusz ??oskot,

Join [email protected] to automatically receive all group messages.