In a lot of cases I might have an existing class with some behavior:class Lion{    public void Eat(Herbivore herbivore) { ... }}...and I have a unit test...[TestMethod]public void Lion_can_eat_herbivore(){    var herbivore = buildHerbivoreForEating();    var test = BuildLionForTest();    test.Eat(herbivore);    Assert.IsEaten(herbivore);}Now, what happens is I need to create a Tiger class with idential behavior to that of the Lion:class Tiger{    public void Eat(Herbivore herbivore) { ... }}...and since I want the same behavior, I need to run the same test, I do something like this:interface IHerbivoreEater{    void Eat(Herbivore herbivore);}...and I refactor my test:[TestMethod]public void Lion_can_eat_herbivore(){    IHerbivoreEater_can_eat_herbivore(BuildLionForTest);}public void IHerbivoreEater_can_eat_herbivore(Func<IHerbivoreEater> builder){    var herbivore = buildHerbivoreForEating();    var test = builder();    test.Eat(herbivore);    Assert.IsEaten(herbivore);}...and then I add another test for my new Tiger class:[TestMethod]public void Tiger_can_eat_herbivore(){    IHerbivoreEater_can_eat_herbivore(BuildTigerForTest);}...and then I refactor my Lion and Tiger classes (usually by inheritance, but sometimes by composition):class Lion : HerbivoreEater { }class Tiger : HerbivoreEater { }abstract class HerbivoreEater : IHerbivoreEater{    public void Eat(Herbivore herbivore) { ... }}...and all is well.  However, since the functionality is now in the HerbivoreEater class, it now feels like there's something wrong with having tests for each of these behaviors on each subclass.  Yet it's the subclasses that are actually being consumed, and it's only an implementation detail that they happen to share overlapping behaviors (Lions and Tigers may have totally different end-uses, for instance).It seems redundant to test the same code multiple times, but there are cases where the subclass can and does override the functionality of the base class (yes, it might violate the LSP, but lets face it, IHerbivoreEater is just a convenient testing interface - it may not matter to the end-user).  So these tests do have some value, I think.What do other people do in this situation?  Do you just move your test to the base class, or do you test all subclasses for the expected behavior?EDIT:Based on the answer from @pdr I think we should consider this: the IHerbivoreEater is just a method signature contract; it does not specify behavior.  For instance:[TestMethod]public void Tiger_eats_herbivore_haunches_first(){    IHerbivoreEater_eats_herbivore_haunches_first(BuildTigerForTest);}[TestMethod]public void Cheetah_eats_herbivore_haunches_first(){    IHerbivoreEater_eats_herbivore_haunches_first(BuildCheetahForTest);}[TestMethod]public void Lion_eats_herbivore_head_first(){    IHerbivoreEater_eats_herbivore_head_first(BuildLionForTest);}
How do you structure unit tests for multiple objects that exhibit the same behavior?
unit testing
This is great because it shows how tests truly drive the way you think about design. You are sensing problems in the design and asking the right questions.There are two ways of looking at this.IHerbivoreEater is a contract. All IHerbivoreEaters must have an Eat method which accepts a Herbivore. Now, your tests do not care how it is eaten; your Lion might start with the haunches and Tiger might start at the throat. All your test cares about is that after it calls Eat, the Herbivore is eaten.On the other hand, part of what you're saying is that all IHerbivoreEaters eat the Herbivore in exactly the same way (hence the base class). That being the case, there is no point in having an IHerbivoreEater contract at all. It offers nothing. You may as well just inherit from HerbivoreEater.Or maybe do away with Lion and Tiger completely.But, if Lion and Tiger are different in every sense apart from their eating habits, then you need to start wondering if you are going to run into problems with a complex inheritance tree. What if you also want to derive both classes from Feline, or only Lion class from KingOfItsDomain (along with Shark, perhaps). This is where LSP truly comes in.I would suggest that common code is better encapsulated.public class Lion : IHerbivoreEater{    private IHerbivoreEatingStrategy _herbivoreEatingStrategy;    private Lion (IHerbivoreEatingStrategy herbivoreEatingStrategy)    {        _herbivoreEatingStrategy = herbivoreEatingStrategy;    }    public Lion() : this(new StandardHerbivoreEatingStrategy())    {    }    public void Eat(Herbivore herbivore)    {        _herbivoreEatingStrategy.Eat(herbivore);    }}Same goes for Tiger.Now, here's a beautiful thing developing (beautiful because I didn't intend it). If you just make that private constructor available to the test, you can pass in a fake IHerbivoreEatingStrategy and simply test that the message is passed on to the encapsulated object properly.And your complex test, the one you were worrying about in the first place, only has to test the StandardHerbivoreEatingStrategy. One class, one set of tests, no duplicated code to worry about.And if, later, you want to tell Tigers that they should eat their herbivores a different way, none of these tests have to change. You're simply creating a new HerbivoreEatingStrategy and testing that. The wiring is tested at integration-test level.