Czy to jest poprawne wykorzystanie dziedziczenia?

Mam pewną hierarchię klas dziedziczących po sobie, każda z nich implementuję tę samą metodę i każda z tych implementacji wywołuje metodę superklasy - z grubsza przedstawia się to tak:

class A {
    public String doSth(){
        return stringBasedOnClassAFields;
    }
}

class B extends A {
    @Override
    public String doSth(){
        stringBasedOnClassBandAFields = stringBasedOnClassBFields + super.doSth();
        return stringBasedOnClassBandAFields;
    }
}

class C extends B {
    @Override
    public String doSth(){
        stringBasedOnClassCBandAFields = stringBasedOnClassCFields + super.doSth();
        return stringBasedOnClassCBandAFields;
    }
}

Chodzi o to, że każda z kolejnych klas dziedziczących zawiera dodatkowe pola a metoda doSth zwraca jakąś konkretną reprezentację takiego przypadku biorąc pod uwagę jej wszystkie superklasy.

1. Czy to jest poprawny design? Szczerze mówiąc, nie podoba mi się wywoływanie super. ale totalnie nie wiem jakim patternem to zastąpić. Próbowałem przepisać to na composition ale mam wrażenie, że nie rozwiązuje to mojego problemu, bo super.doSth() byłoby zastąpione wywołaniem objectA.doSth a sama hierarchia byłaby mniej czytelna.
2. Jak wygląda kwestia testowania takiego kodu? zamokować super.doSth i robić assercje tylko na wartości zwróconej przez doSth() bazującej na wartościach pojedyńczej klasy?

Chętnie uszczegółowię pytanie jeśli coś pominąłem, nie chciałem żeby przykład stał się mało czytelny.

Użyj wzorca kompozyt. W twoim przypadku będzie to jego uproszczona forma, czyli dekorator

Weź konkretnie napisz, co chcesz osiągnąć i jakie to są klasy, co robią. Może to się inaczej da rozwiązać.

Tworzysz tu jakiś string na podstawie stringów ze wszystkich poprzednich klas? Innymi słowy jeśli będziesz miał taką hierarchię
A -> B -> C -> D
to wynikowy string będzie (w uproszczeniu) czymś jak:
A.text + B.text + C.text + D.text
?

Jeśli tak, to czemu w ogóle dziedziczenie? Nie lepiej po prostu użyć jakieś tablicy (albo listy/kolekcji/co tam innego masz w tej Javie) ze stringami? Ew. dziedziczenie + tablica na stringi, do której każda kolejna klasa dorzuca swojego stringa.

Nie jestem pewien jak to będzie wyglądać dokładnie w Javie, ale w JS można coś takiego zrobić:
http://jsfiddle.net/dxnhwv92/

Pytanie tylko, czy to dobry design. Ale myślę, że to zależy od tego, co chcesz osiągnąć, co się kryje pod tymi A, B i C? I jaki jest cel tego, co robisz?

Mam wrażenie, że dziedziczenie jest o tyle odpowiednie, ponieważ odzwierciedla biznesową hierarchię t.j. każda subklasa jest trochę pokrewna do superklasy różniąc się od niej dodatkowymi polami. Sama w sobie klasa A ma sens, ale również klasa C<-B<-A też ma sens bo jest konkretnym przypadkiem z dodatkowymi polami zawierającymi się we wszystkich z tych klas.
Natomiast pattern decorator o ile miałby zastosowanie w przypadku gdy klasa A byłaby zawsze klasą bazową, a B i C dodatkową dekoracją w tym sensie, że jest to dalej głównie klasa A z dodatkową charakterystyką o nazwie B i C tak w przypadku gdy B i C są same w sobie biznesowo innymi obiektami już nie bardzo.

Może szukam dziury w całym , a wywołanie super.doSth nie jest aż takim anty patternem?

Bardzo ogólnie to opisałeś. Wywołanie metody z klasy nadrzędnej jest ok. Bardziej mnie niepokoi ten klasyczny przykład dziedziczenia, oddający strukturę biznesową, czyli jak rozumiem coś takiego:

class Person{
private String name;
....
}

class Employee extends Person{
private Double salary;
....
}

Generalnie da się, tylko ile razy bym tak nie próbował modelować danych to dostawałem kopa, bo okazywało się, że hierarchia klas może i jest sensowna, tylko bardziej utrudnia życie niż pomaga. Zwykle lepiej zrobić to tak:

class Employee {
private Person person;
private Double salary;
....
}