Wrong.

A bad API is not improved by a set of tests that nail down every aspect of its misbehaviour. Furthermore tests are code like any other, and good coding principles apply just as much.

About your main question, I agree that inheriting the tests is better, and here is the argument that I would give back to the other programmer. Suppose that your subclass is written and you copy tests. If anyone now extends the superclass, then either subclasses have untested behaviour or else the implementer has to track down every subclass and cut-and-paste the behaviour. This is exactly the kind of cut-and-paste which is likely to break that object-oriented techniques are supposed to protect you from.

However if your strategy is to inherit tests then both your present and future behaviour will get tested. True, it is possible to break your module by changing just the core module and changing its tests without notifying you. But this breakage is exactly the same risk that anyone using any module faces. No strategy can really protect you from rogue modifications, and attempting to do so by producing masses of redundant code loses productivity to what is really an education issue.