¿ªÔÆÌåÓý

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

 




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

If you can see that you need to query internals to know whether something works or not that is a smell. If you try to fix it right then it is likely to be easier than if you wait. If you try to fix it and make it worse then try again. That is what version control was invented for (precisely.)?

If you need help understanding when and why to change stuff I recommend the eLearning product from Industrial Logic.?

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


I was responding more to the wording "used deep in implementation" than the code in your example. However, just because it is a direct collaborator doesn't mean you are out of the water. Tight coupling between the SUT and a direct dependency is a smell (Inappropriate Intimacy, most likely, though it could be a couple other things too.)?
Join [email protected] to automatically receive all group messages.