Ich habe eine Unit-Test-Klasse Tester ; Ich möchte, dass es auf private Felder einer Working -Klasse zugreift.
Ich habe die folgenden Optionen:
public - hässlich test_getVariable() - überkompliziert friend class Tester zu Working hinzu - dann "weiß" das Programm explizit über den Tester, was nicht gut ist Mein Ideal wäre
%Vor%wo Working über TestBase weiß, aber nicht jeden Test ... aber es funktioniert nicht. Anscheinend funktioniert Freundschaft nicht mit Vererbung.
Was wäre die eleganteste Lösung hier?
Im Allgemeinen sollten Ihre Komponententests keine privaten Variablen auswerten. Schreiben Sie Ihre Tests an die Schnittstelle, nicht an die Implementierung.
Wenn Sie wirklich überprüfen müssen, ob eine private Variable ein bestimmtes Merkmal aufweist, sollten Sie in Erwägung ziehen, assert() zu verwenden, anstatt zu versuchen, einen Komponententest dafür zu schreiben.
Eine längere Antwort (geschrieben für C # statt C ++, aber die gleichen Prinzipien gelten) ist Ссылка .
Ich stimme Trotts Antwort zu, aber manchmal fügen Sie Komponententests zu altem Code hinzu, für den das nicht vorgesehen ist es. In diesen Fällen erreiche ich #define private public . Es ist nur in Unit Tests, und es ist nur für, wenn Refactoring zu teuer ist, um zu stören. Es ist hässlich, technisch illegal und sehr effektiv.
-fno-access-control Wenn Sie nur GCC verwenden, können Sie beim Kompilieren der Komponententests die Compileroption -fno-access-control verwenden. Dies führt dazu, dass GCC alle Zugriffsprüfungen überspringt, das Klassenlayout jedoch immer gleich bleibt. Ich weiß nicht, ob es eine ähnliche Option für andere Compiler gibt, also ist dies keine allgemeine Lösung.
Versuchen Sie sehr, Ihren privaten Code mit Ihrer öffentlichen Schnittstelle zu testen. Es ist nicht nur anfänglich weniger Arbeit, aber wenn Sie die Implementierung ändern, gibt es eine viel höhere Wahrscheinlichkeit, dass die Komponententests immer noch funktionieren.
Das heißt, irgendwann müssen Sie nur auf die Innereien stochern, um eine gute Testabdeckung zu bekommen. In diesem Fall verwende ich ein Idiom, das ich expose nenne. Es ist ein Witz drin, wenn Sie darüber nachdenken.
Foo-Klasse, die getestet werden muss
%Vor%foo_exposed.h ist nur für den Einheitentestcode verfügbar.
%Vor%Wie es in Unit-Test-Code verwendet werden würde
%Vor%Wenn Sie das unbedingt tun müssen, könnten Sie Ihren Code bedingt kompilieren, so dass TestBase nur ein Freund ist, wenn Sie Unit-Tests durchführen:
%Vor%Ich habe dies getan, indem ich eine Kopie meiner Klassenheaderdatei in meinem Test verwendet habe, in der der Zugriffsbezeichner "private" fehlt. Die Kopie wird vom Makefile im Testverzeichnis generiert, so dass die Kopie neu generiert wird, wenn sich das Original ändert:
%Vor%und das 'test' make-Ziel hängt von mock_class_header.h ab.
Dies gewährt Zugriff auf alle privaten Membervariablen im Test, obwohl die reale Bibliothek mit diesen Membervariablen als privat kompiliert wurde.
Tags und Links unit-testing c++