Minimal

You can predict that it, too, will end up requiring the functionality shared by the first two classes. For example, it may be a third wizard page you’re creating—you know you’re designing a wizard page, just like its forebears. However, as you’re diligently writing one test at a time for this new class, can you justify taking the leap to include all of that existing functionality without having already written tests for it? Or does your conscience kick in and force you to go through the rigmarole of duplicating all of that stuff again, just to prove that reusing the code is valid?

I guess there are a couple of things to consider here:

1. How comfortable do you feel about taking the shortcut? Are you disciplined enough to make sure that you test all inherited behaviour on the new class?
2. More importantly, which path is going to provide greater productivity? If there’s a non-trivial risk that early adoption of the superclass will adversely affect the quality and slow down progress, perhaps the better path is to duplicate after all.

Actually, I’m still not comfortable with this conclusion. Sure, productivity has to be the deciding factor, but it’s a judgement call as to how your decision will affect it. There seems to be no hard and fast rule—personal experience and confidence appear to be the key. Damn. One thing I am pretty sure of, however, is that if you’re going to get it wrong, get it wrong quickly. ;-)

Update: following some comments from Kevin Rutherford on the Stacking unit tests post, I’m rethinking what I’ve said above. Do I need to test all inherited behaviour on the new class? Probably not—I’ve already got tests for it associated with other classes. All I need to test is the various behaviours I’m implementing for the new class and they’ll be very class-specific.