Unfortunately, I don't think there's an easy way to mock
I can see that you want to write a "clean" unit test for A that does not rely on B, which is a reasonable aim. But if A is calling a protected method on its superclass, Java makes it hard to decouple the two classes.
This is one of many examples where using inheritance couples classes more closely than you'd like.
Ideally A would wrap B rather than extending it (i.e. using composition rather than inheritance), and would then call
myB.calculate rather than
Both classes could implement the same interface (e.g. Calculable) to allow them to be treated polymorphically by clients. This approach would requre B.calculate to be public, or at least package-public. Your unit test could set up an A that wraps a mock B, thereby solving your problem.
I think you have to choose between increasing the visibility of calculate(), as described above, and writing a clean unit test - I don't think you can have both.