Should all class public methods come from an interface?

Question

I'm currently learning about TDD techniques, one of the suggestion is to test only public methods and skip the private ones. I have also been reading about Mocking. If I want to mock a certain method, then it needs to come from an interface or be marked as virtual. When I start developing my application I don't know which methods I will want to mock while creating unit tests, because of that I think it's best to make them all available for mocking.

I assume that making all methods virtual isn't the best solution, then the alternative is the interface approach mentioned above.

Is that the right direction or do I miss something obvious?

Answer 1

• Fabio touched on it in his comment - it is perfectly legit to start using a dependency in a test before any interface or implementation code exists for it.

  When you feel that your object under test needs indirect input from somewhere else, or that you need to test indirect outputs of your object, start typing your stubbing or mocking code as if those external dependencies existed. Then use IDE productivity features to generate the interfaces and their method signatures.

  This is called "programming by wishful thinking" and is used a lot in outside-in TDD.

  Your question makes less sense in that context, since you wouldn't create any new interface or any method inside an existing interface without mocking them first.

• Another context is when you create dependencies by extracting new classes during the Refactor step of the TDD cycle and, in a more "Classicist" style, decide not to test them with mocks.

  Here, the answer to your question Should all class public methods come from an interface? is clearly: "no". You can perfectly have a TDD-written test that tests objects A and B without either of them implementing an interface.

  However, I would use this approach only when the extracted dependency is in the same layer as the object under test, not at application boundaries/seams. Having interfaces at architectural boundaries is often more valuable because it is usually where you get the most fragility, the least performance, the most complex configuration, and the highest likelihood of needing multiple implementations of the same abstraction.

Answer 2

Should all class public methods come from an interface?

No -- it's a really interesting constraint to experiment with, but it isn't necessary.

If I want to mock a certain method, then it needs to come from an interface or be marked as virtual.

Mocking a specific method makes me twitchy -- if you are trying to mock the method, rather than the object, it begins to sound like you don't really have the correct grain to your objects.

If I ran into that need, I would look very carefully to see if I really have two objects -- one that is responsible for the bit I want to mock (and nothing else), and another that uses the previous object as a collaborator.

(Part of the point of tdd is to be sensitive to when your design is breaking the rules, because that often indicates a weakness in the design.)

As a rule, we shouldn't need to mock arbitrary public method, so I would not encourage you to optimize for that use case prematurely.

Answer 3

I'm currently learning about TDD techniques, one of the suggestion is to test only public methods and skip the private ones

Yes, TDD focuses the efforts on defining the test through the contract first and getting the implementation later. We define first the methods (mostly public), their arguments, their returning types and the exceptions that can be thrown.

These contracts might or might not come from interfaces or virtual methods. They could be mere empty methods of a new class. So, no, they don't all come from an interface. TDD will not force your design in that way. ¹

I have also been reading about Mocking

Here is where you are getting lost. Mocks (IMO) are an advanced technique for testing. Not directly involved with TDD. You can still follow TDD with no mocks. Mocks are addressed for testing components with heavy dependencies (as @guillamue31 commented in his answer). it provides a "fake" instance of a given interface. One which behaviour can be programmed in order to meet the conditions required for the use case under test. It could be a class too. Yes, concrete classes can be mocked too.

When I start developing my application I don't know which methods I will want to mock while creating unit tests, because of that I think it's best to make them all available for mocking.

Fine. Let TDD tell which components are good candidates to be mocked. After several iterations of TDD, once tests go green, it's easier to see which components need decoupling and therefore, the candidates to be mocked. But keep in mind that not every single dependency implies an interface. That's up to you to decide based on the requirements, needs and preferences.

---

^{1: I would like to share a video of Sandro Mancuso implementing Rovers Mars kata. You will see that he didn't use any interface to test contracts. Mancuso is very in favour of this methodology and he encourages it to all his employees}

^{2: Note that Sandro is following TDD and Rover's methods are protected!!! He is playing with the package scope. Test and concrete class are in the same package. So, TDD doesn't even force us to define methods as public.}

Answer 4

No. You only need Interfaces for classes which are used as dependencies

for example:

public class Application
{
     private IService service;
     public void Main() {...}
}

public class Service : IService
{
    public Customer GetCustomerForOrder(Order order)
}

public class Customer 
{
    public decimal GetBalance() {...}
}

public class Order 
{
    public decimal GetTotal() {...}
}

Here only Service needs to have an interface. When we test Application we will want to inject a mocked Service and the Interface enables that, plus general replacement with alternative implementations.

Mocking Application doesn't help you at all.

Customer and Order can be tested directly as they have no dependencies.

Answer 5

Ideally, you should test all public methods, which does indeed mean that all public methods should be mockable.

Due to confusion in the comments, I want to point out that with "mockable", I mean "able to be tested". In other words, part of the interface definition (or, as per the suggestion in the question, made virtual, though I'm not a fan of this approach over interfaces)

In reality, you won't always test everything. In my current project, for example, I've had to struggle just to get the time to implement unit tests (management didn't consider it necessary). As a compromise, we agreed to only test the business logic that changes the state of the objects, and to not test retrieval methods which only fetch data.

I assume that making all methods virtual isn't the best solution, then the alternative is the interface approach mentioned above.

Is that the right direction or do I miss something obvious?

I do not see a reason to use the virtual approach. Interfaces are already much more commonplace (especially when coupled with dependency injection), and they already cover all the necessary bases.

So I suggest using interfaces instead of virtual methods.

If someone can show me an valid case where virtual methods are better than interfaces, I'm happy to hear it.

Note
Even if you know you're not going to test certain public methods (such as the data retrieval methods in my current project), you should still include these methods in the interface. Just because you're not testing them today doesn't mean you won't test them tomorrow.