I look at it this way: I write objects because I want them to behave in particular ways. If I can save code by factoring common stuff out into superclasses, great, but at one conceptual level, that's just an organizational optimization. If I can get some behavior for free by subclassing an existing class, great. But again, that's an optimization (saving the time and effort it would take me to redo the equivalent work). What I still have is objects with behavior, and I want unit tests that cover that behavior. That means complete coverage of every class. Now, if it just so happens that there's some common testing that can be factored into a unit test superclass, great. But again, that's just an organizational optimization.

I might end up with an inheritance hierarchy in my tests that doesn't match the inheritance hierarchy in my domain objects. Though I've factored domain behavior into abstract superclasses, I don't intentionally set out to write unit tests for those superclass. I might get the same effect by factoring unit tests, but I might not. But in all cases (in theory, at least :), my non-abstract classes have unit tests that cover the behavior I'm interested in.

That's a slightly different way of looking at the world than the two options in your question allow, but it works well for me.