Eli Lopian’s Blog (TypeMock)

“When you find that an interface and implementation have exactly the same public methods, it is a sign that the interface is not exposing a trait of the object but the Object itself.”

What if there is more than one implementation of that interface (in the production code)?

I agree over-abstraction merely for testability is wrong but configuring runtime replacements of concrete classes for the same purpose sounds equally awkward…

Yoni,
I must agree that AOP does sound awkward, but more on that later.

When there is more then 1 implementation of an interface and both have the same public methods as the interface - It is still a code smell.
In most cases the code is not designed well. You will almost ONLY see this in ‘Testable Code’.

An interface in a good design exposes a trait of an object, Take IList - when an object implements IList it has the trait of a list. When an object implements IEnumerable, you can iterate on the object. Notice that each interface is a trait that we add to our objects.
Take ArrayList that implements IList, it has many more public members then IList. Notice that even Count is not a member of IList. This is a because IList is a Trait of a list and not just an Interface used to isolate and test the code.

So basically as you say, the choice is:
1. Create these interfaces, deliver them in your production code (over abstraction)
2. Use tools that enable you to test your code without mucking with the design (automatic isolation by adding a testable aspect* to you code)

And yes AOP is really weird…

* aspect as in Aspect Oriented Design

Let us consider System.Data.IDbConnection. When I create a gateway to my new database I would probably create a connection class which exposes that interface and requires no more public members in order to function as an ADO.NET provider, is this a code smell?

An interface is an abstraction that should have different concrete implementations, this does not require the implementations to have any other public members.

And, besides, if there is more than one implementaion then the code that uses the interface can be tested using a mock without designing for testability (consider code that operates on an IList).

Yoni,
That is a great example.
Take a look at SQLConnection is has 3 time the amount of public API’s then the IDbConnection that it implements. OracleConnection has twice as many.

I am sure that if you had to create your own Connection Class it would have to have more public methods then just the interface.

So I still stand behind: “If your interface and concrete class have the same public methods, something is probably wrong with your design”.
You might find having a base class is a better design or if think about the Traits that the object has you can extract those into interfaces.

Of course if your production code REQUIRES using pluggable and changeable components, you will have to use some kind of Dependency Injection and then this will lead to the code being testable, but the business requirements should guide you NOT the testability.

Making your code testable, is like creating a modular TV Set, with an opening at the back of the set that you can easily open (without screws) put your hand through, dislodge the Remote Receiver (which you can switch with a mock Remote and test the TV), same goes with the volume controls, speakers etc. etc.
This is great and now you can sell the Modular TV Set to the world.
The thing is that it is more expensive to make (in code this means that the code is more complex) and there is no real business value. Who wants to pay more for a modular TV set?
Of course you can say that the TV set have been tested and this has value. But then with TypeMock you can do the same and lower the price of the TV set because you don’t have to make it modular.

If you are familiar with the GoF design patterns it won’t come as a surprise that almost all of them are cases of classes that expose the same public interface as the interfaces they implement.

Take a look here:
http://www.dofactory.com/Patterns/Patterns.aspx
(this site uses pure abstract base classes but that is exactly the same as using an interface).

:-)
I understand that we differ here, this is of course my opinion, you may not agree and design differently.
The GoF design patterns may have examples like you say, but these are examples, and in real life code you don’t normally just print text to the console.

My point is: when you find classes that expose only the same methods as the interface they implement - Take a GOOD look at your design
Your code might be over abstracted.

[…] There is an ongoing conversation in the blogsphere about testing, specifically whether the design and code should be modified to support testing.  See Roy Osherove, Eli Lopian, and Stop Designing for Testability. […]

“Have you ever tried to browse a code with loads of interfaces, it take ages because you have to keep finding the concrete implementation, and the place where the instance was created.”

I’d suggest that that’s a problem with the tool. It _should_ give you a drop-down of the interface and all types that implement it in an intellisense-y (resharper-y) fashion.

This is probably just me, but I consider mock based tests a design smell. You see, mocks and I are not friends. Each time I found a useful mocking framework, I failed.

The root cause of my failure is my mock based tests verifies implementation and not behavior. That makes refactoring hard.

Last time I gave up a third of my tests, because I lacked the energy to do the right thing. The tests broke due to internal implementation changes, even when external behavior was unchanged.

Thanks for posting your ideas.
JH, thanks for the pointer, I was really trying to point out that introducing IoC, lowers the maintainability of the code.

Thomas, I understand where you are coming from, there is a lot of truth in what you say. You have to know when to use mocks.

@ Eli

The modular tv analagy would fit only if the tv owners were trying to add additional features or change existing features after the set was purchased. I don’t know many TV owners who try and upgrade their analog TV to support HiDef. Every application I’ve worked on, however, has gone through an equivalent large-scale feature upgrade.

I would agree that concepts like IoC and dependency injection are code smells in an application which does not need to evolve with business requirements, but until I meet an entepreneur with a set-in-stone business plan, I will continue using my DI container and programming to interfaces.

On the other hand, my view of this topic is only through the eyes of enterprise application development. If I were developing something else (say..a mail server or general purpose library), my opinion would probably be quite different.

Evan,
Thanks for your post,
Perhaps the analogy wasn’t so good.
The point is: Once a business requirement arises that required IoC, by all means do it. But not one second before.
(As you say) We are not profits and we don’t know what future requirements will be needed. Lets do it the Agile way:
Have a test bed, so that we can re-factor our code base easily and add features as they come. Do the Simplest thing that can work.
Don’t start putting hooks, this is NOT the simplest thing that can work.

[…] If you are interested in Agile methodologies, go see James Shore’s Agile Book draft. He is soliciting feedback from the community. The book promises to be very interesting. It’s an O’Reilly so it has to be good! I can’t wait too see the colophon design! We all know that Unit Testing is a good thing. Do yourself a favor, and check out Roy Osherove’s The Art of Unit Testing blog site. It’s a subset of his main blog related to the book he is writing and unit testing in general. Roy and Eli Lopian have an ongoing discussion about the merit of Testable Object Oriented Designs or the lack thereof. All I can say is that Eli has definite opinions! Yet another blog to add to my growing collection… […]

Nice

Cool…

Cool!

Interesting…

Cool!

interesting

Cool…

interesting

Nice!

Sorry