Ich war in vielen Situationen, in denen meine Kernlogik in privaten Methoden liegt. Wie würden Sie bei Unit-Tests vorgehen, gibt es irgendeine Art von Kompilierzeit-Manipulation, um Kompilierungsfehler für unbekannte / private Methoden zu ignorieren? Ich weiß, dass ich für den zweiten Teil des Codes performSelector verwenden könnte, aber ist das eine vernünftige Lösung?
Zum Beispiel:
%Vor%BEARBEITEN:
Hier ist ein Beispiel, um zu zeigen, warum ich das Gefühl habe, dass ich einige private Methoden testen muss. Sind diese Tests nicht sinnvoll? Wie sonst würde ich testen, dass das Aufrufen von Clear tatsächlich tut, was es tun soll?
%Vor%Methoden sind niemals "privat" in dem Sinne, dass, sobald eine Klasse eine Methode implementiert, sie jemand anderem schicken kann.
Nehmen wir an, Sie haben eine Klasse Foo mit einer "privaten" Methode bar , die nicht in der Interface-Deklaration enthalten ist. Sie könnten von überall aus bar aufrufen, obwohl Sie möglicherweise eine Compilerdiagnose erhalten.
Der wahrscheinlich einfachste Ansatz besteht darin, die Methoden in einer Kategorie zu deklarieren, die in Ihren Tests verwendet wird. Zum Beispiel:
%Vor% Nun können Sie sie verwenden, ohne dass sich der Compiler beschweren muss. Beachten Sie, dass die Methoden nicht in einer tatsächlichen MyPrivateMethodsUsedForTesting -Kategorie implementiert werden müssen. Diese Technik wird manchmal auch als "informelles Protokoll" bezeichnet.
BEARBEITEN
Wie von anderen auch bemerkt, sollten Sie, wenn Sie auf private Methoden zugreifen müssen, Ihr Design wahrscheinlich erneut besuchen. Nach ca. 30 Jahren gibt es definitiv Zeiten, in denen Sie speziell für Tests auf private Dinge zugreifen müssen, aber meistens bedeutet dies, dass eine Art Design-Review in Ordnung ist.
Sie sollten Ihre privaten Methoden nicht direkt testen. Stattdessen müssen Sie sie mit den öffentlichen Methoden testen. Hier ist ein Link zu eine Frage zu programmers.stackexchange.com Erörterung der Angelegenheit.
Die allgemeine Idee der Antworten ist, dass Sie (oder jeder andere, der Ihren Code verwaltet) jederzeit frei sein können, Ihre privaten Methoden zu ändern, indem Sie die Signatur ändern, die Implementierung ändern oder sie komplett entfernen. Niemand außerhalb Ihrer Klasse sollte sich darum kümmern - schließlich ist das der Hauptgrund dafür, dass diese Methoden an erster Stelle privatisiert werden.
Wenn Sie Ihre private Methode auf eine inkompatible Weise ändern, müssen Unit-Tests Ihrer öffentlichen Methoden abgebrochen werden. Ansonsten haben Sie Ihre öffentlichen Methoden nicht gut getestet. Effektiv macht dies das Testen von Einheiten privater Methoden unnötig.
Im Allgemeinen sollten Sie private Methoden nicht testen.
Die öffentlich zugänglichen Methoden sagen Ihnen, was Ihre Klasse macht - das ist es, was Ihnen wichtig ist, und Sie sollten diese testen. Die privaten Methoden befassen sich mit wie Ihre Klasse ihren Job macht, Ihr Test sollte sich nicht darum kümmern, wie der Job erledigt wird, solange er korrekt ausgeführt wird.
Wenn Sie eines Tages entscheiden, wie Ihre Klasse ihre Arbeit verrichtet (dh indem Sie den Code in Ihren privaten Methoden ändern), ohne was Ihre Klasse tatsächlich ändert, sollten Ihre Komponententests fortfahren bestehen. Wenn Sie versuchen, die Interna Ihrer Klasse zu testen, erstellen Sie einen Sprachtest, der brechen kann, obwohl die Klasse noch immer korrekt funktioniert.
Wenn Sie Schwierigkeiten haben, Ihre Klasse gründlich zu testen, indem Sie nur öffentliche Methoden verwenden, ist dies ein Warnsignal dafür, dass Ihre Klasse zu groß ist - ziehen Sie in Betracht, sie in kleinere Teile aufzuteilen.
Sie müssen diese nicht Unit-Test - in der Tat sollten Sie nicht Sie werden Ihre private Methode indirekt über Ihre öffentlichen Methoden testen. Private Methoden sind Hilfsmethoden, um die Aufgabe für Ihre öffentlichen Methoden zu erledigen.
Da Sie frei genug sein sollten, Ihre privaten Methoden zu ändern, wie Sie Unit-Tests mögen, wäre das auch kontraproduktiv.
Achten Sie jedoch darauf, alle Fälle für Ihre öffentlichen Methoden zu testen, damit alle Ihre privaten Methoden abgedeckt sind.
Tags und Links objective-c unit-testing ios