Should I unittest private/protected method

From a theoretical point of view, you only need to test public methods of your instantiable classes (in standard OOP languages). There is no point in testing the internal behaviour because all you want is "which output for that input" (for a particular method, or for the entire class). You should try to respect it as much as you can because it forces you to ask some questions about the encapsulation of your class and the provided interface which may be decisive for your architecture.

From a pragmatic point of view, you can sometimes have some abstract helper classes with no implemented concrete subclass or an abstract class factoring 90+% of its child classes and where it would be too hard to test the output without plugging into a protected method. In those kinds of cases, you can mock a subclass.

In your straightforward example, I would suggest you to only test the class Tiger (and only the public method eat).

Just a note for people thinking to TDD. In TDD, you shouldn't have started to code the class Mammal before the class Tiger because Mammal should be the result of a refactoring phase. So, you certainly woudn't have any specific test for Mammal.

The way I would approach this is:

• Create a minimal testable subclass of Mammal which provides minimal implementations of the two protected methods that allow you to unit test the behavior of the public methods.
• Write separate unit tests for each subclass which again test the public methods on Mammal, but are asserting the behavior that is specific to that subclass.

This should give you the necessary testing coverage with a minimal number of tests.

One alternative approach would be to test the subclasses only, and on one of the subclass unit tests also assert the features specific to Mammal. This avoids the need to create a specific testing subclass, however two disadvantages are:

• You are no longer testing Mammal in isolation, and therefore the tests on the Mammal specific code are susceptible to failing because of issues in the subclass.
• It may be less obvious to others how and where the properties of Mammal are being tested.

When testing you should focus on the outside behaviour of your code, not on implementation details. I don't know the context, so I'll just make some huge assumptions here.

Do you really care about the behaviour of a (potentially abstract) Mammal superclass? Is the reuse-through-inheritance relationship that important? What if you decide to replace the inheritance relationship to a composition-based strategy?

I would focus on testing the behaviour of the classes you actually care about: "Does a Tiger eat as expected?" instead of testing some abstract superclass that is only introduced for code reuse.