¿ªÔÆÌåÓý

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

 

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 <mateusz@...> wrote:
?

On 14 January 2014 16:31, Avi Kessner <akessner@...> 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,


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