Oct
4

Low Coupling is NOT a Silver Bullet

Author Eli Lopian    Category .NET Tests     Tags

I will start with some more post about TypeMock and Testability issue.

Holy crap, this thing is hot. In technical terms, you might call it the bomb-diggity.
I haven’t been this stoked about a technology for quite some time.

TypeMock is absolutely awesome.  No, no, it is sexy.  It is dead sexy.  TypeMock has opened up a whole new world for me in unit tests. 
Simply beautiful. 

Sorry, Travis, no offense, but when you wrote this you showed that you still don’t get the idea of unit testing and the benefits that come from them…

Question to Miki:

Is the ‘pass the interface into the method’ really a better design? Think about it for a moment. You now require the WorkingClass to know about an interface that he doesn’t really need to know about. So you are actually lowering the cohesion (by having a less encapsulated system) in order to have a lower coupled system. This is what design is all about – balance, there is no silver bullet.

So is the design balanced? or do we blindly always strive to have lower coupled system at the price of other object oriented practices?

ps. I know that you can have a design the has both options and have the WorkingClass use only methods that do not require the interface, but then you are really dirtying the code just for the tests.

Bookmark and Share

3 Comments to “Low Coupling is NOT a Silver Bullet”

  • paraesthesia October 5, 2006 at 7:12 pm

    [...]  Mocking Debate Heats Up – I posted last week a short discussion about whether mock objects are too powerful for most developers.  [...]

  • Eli Lopian’s Blog (TypeMock) » Blog Archive » Design and Testability - YAGNI March 6, 2007 at 11:02 pm

    [...] So, Does testing - driving your design, actually create the best design? I am not sure.It does one thing for sure, It creates a low coupled (modular) design. But low coupling is NOT a silver bullet. A good design has to take and BALANCE many factors, this is a complex task. Adding Testability to these factors might unbalance your design. [...]

  • Kikih November 28, 2014 at 7:01 pm

    Hi rliesenfield,Thanks for the aporceiatipn and the feedback.I’m quite sure I never specified the scope of a unit in a unit tests. Our units are usually a combination of a few classes so that we have a good balance between maintainability and refactorability. We even have integration tests that touch a database, file system or other expensive resource. For me a unit test is just an automated test that is extremely fast, runs in-memory and doesn’t have any side-effects. The dependencies part usually happens without thinking because you want your classes to be easily testable. Refactoring dependencies behind an interface is an easy solution for the need to introduce a backdoor (see XUnit Patterns for more examples).I think you’re right about the subtle difference between DIP and IoC, though I strongly believe that the Service Locator pattern is an anti-pattern. But I do agree that there isn’t a silver bullet and careful consideration of the pros and cons is required before choosing a particular tool, framework or pattern.

Post comment