Unit Test mit Vererbung



  • Ich arbeite mich gerade in Unit Tests ein da ein bestehendes Programm getestet werden soll. Gerade für C++ gibt es ja einiges an Material im Netz aber wo ich noch stocke ist bei Vererbten Funktionen.

    Ich habe eine Klasse die quasi sämtliche Ihrer Funktionen aus verschiedenen anderen erbt. Wie muss ich da jetzt vorgehen um die Klasse testen zu können? Dazu fehlt mir bislang ein wenig der Ansatz und die Google Suche ist auch nicht so richtig ergiebig ausgefallen.



  • Reicht es nicht die Klassen selbst zu testen? Vererbte Funktionalität zu testen sollte doch eigentlich redundant sein. Wenn das nötig ist, riecht das stark nach einem Designfehler.



  • Du meinst die Klasse erbt Methoden mit Implementierung? Die eigentlich Frage die sich hier stellt ist, teste ich die Methode einmal im Test der Basisklasse, die die Implementierung bereitstellt oder wiederhole ich den Test in alle erbenden Klassen (die die Implementierung ja evtl. überschreiben).
    Normalerweise teste ich solche Methoden nur einmal im Basisklassen Testn Nur wenn sie überschrieben wird gibt es im Test der erbenden Klasse einen erneuten Test. Falls die Basisklasse abstrakt ist definieren ich im Test eine Dummyklasse die von der Basisklasse erbt und alle rein virtuellen Methoden trivial implementiert.

    Je nach Testframework kann man auch eine Testbasisklasse erstellen und diese in den Testcases der konkreten Klassen wiederverwenden.



  • Ja, so wie brotbernd es meint kommt es der Sache schon recht nahe. Mir ging es erstmal darum ob ich die Basisklasse testen sollte.
    Allerdings geht mein Problem noch etwas weiter. Es geht hier um eine sehr hardwarenahe Programmierung die das Problem für mich hat das so gut wie jede Methode der Klasse die ich eigentlich testen will von einer Ebene tiefer erbt. Dort wird allerdings auch wieder von weiter unten geerbt bis ich quasi kurz vor der Hardware Abstraction stehe. Ich müsste nun also im Prinzip von ganz unten anfangen und erst die Hardware Abstraction Klassen testen und mich dann hocharbeiten um da dann noch geerbte überschriebene Klassen zu testen?



  • Üblicherweiße macht man das so. Man fängt im kleinen an zu Testen und geht dann über auf die Zusammengesetzten Sachen. Wenn man sich nicht sicher ist das die Grundlage funktioniert ist das Fehlerfinden bei einem Fehlverhalten der Übergeordneten Ebene ja ebenso wieder Rätselraten...

    MFG



  • Alles klar, dann besten Dank erstmal.
    Jetzt habe ich allerdings noch ein Problem mit dem Makefile aber ich denke dafür mache ich nen neuen Thread auf.



  • Ich muß doch nochmal was hinterherschieben.
    Es handelt sich wie bereits angesprochen um hardwarenahen Code (läuft auf einem embedded system). Dieser Code ist auf meinem Entwicklungsrechner ohne die entsprechende Spezielle IDE nicht kompilierbar (Mikroprozessorspezifischer Kram fehlt).

    Aus diesem Grund kann ich nicht "ganz unten" zu testen anfangen da dort eben vor allem Schnittstellen sind die mit der Hardware sprechen wollen.

    Die Klasse die ich allerdings testen möchte hat nichts mit der Hardware zu tun und ist standard C++ Code der mit dem g++ übersetzt werden kann. Wie bereits geschrieben laufe ich da aber in eine Abhängigkeeitshölle da der Header der Klasse 6 andere inkludiert, deren Header wiederum eine Hand voll andere inkludieren und auch deren Methoden aufrufen usw..
    Ich suche jetzt nach einer Möglichkeit zum Zwecke des Testens diesen Abhängigkeitsbaum "abzuschneiden". Ich möchte das meine zu testende Klasse noch genau eine Methode einer anderen Klasse aufrufen kann. Der ganze Rest den meine zu testende, oder auch die aufgerufene Klasse inkludieren möchte ich abschneiden möglichst ohne den Produktivcode anzufassen. Ist das möglich? Hat da jemand das richtige Stichwort für mich?



  • TheDoctor schrieb:

    Hat da jemand das richtige Stichwort für mich?

    Test doubles, mocks, stubs.
    Das sind aber auch nur die normalen OOP Techniken um Abhängigkeiten zu reduzieren (Dependency Inversion Prinzip).


Anmelden zum Antworten