Code reusability/inheritance introduces pointless testing
Say I have a bunch of classes that imitate cars: SportsCar, Truck, and SUV. All of these classes share some public methods like start() and stop() which they inherit from an abstract class Car. While they have their differences, imagine they all share some form of private functionality. They all might use the same private method openTrunk() or pumpFuelToEngine(). I don't want to have to write three different openTrunk() methods, so I put them in Car as protected/package-private method instead for code reusability. According to what I have been taught so far unit tests should test the public/protected/package-private interface of a class. These previously trivial and private methods are now reachable for any (test-)class inside of the package, which means they are subject to testing. It seems to me these tests become useless, or even harmful, as they test implementation and not behaviour. Do i skip testing these types of methods, or is there some design solution or unit testing princple i am overlooking? Perhaps the common functionality of these methods imply they should belong to another class?
Say I have a bunch of classes that imitate cars: SportsCar, Truck, and SUV. All of these classes share some public methods like start() and stop() which they inherit from an abstract class Car. While they have their differences, imagine they all share some form of private functionality. They all might use the same private method openTrunk() or pumpFuelToEngine(). I don't want to have to write three different openTrunk() methods, so I put them in Car as protected/package-private method instead for code reusability.
According to what I have been taught so far unit tests should test the public/protected/package-private interface of a class. These previously trivial and private methods are now reachable for any (test-)class inside of the package, which means they are subject to testing. It seems to me these tests become useless, or even harmful, as they test implementation and not behaviour.
Do i skip testing these types of methods, or is there some design solution or unit testing princple i am overlooking? Perhaps the common functionality of these methods imply they should belong to another class?
