Ich hasse es, das hier wieder zu erwähnen, aber ich versuche wirklich zu verstehen, wie ich mit meinen Tests etwas schützen kann.
Ich habe eine öffentliche Methode (unten), die eine private Methode aufruft, bevor eine andere Methode aufgerufen wird, die tatsächlich etwas unternimmt. Ich möchte sicherstellen, dass der Aufruf der privaten Methode nicht entfernt wird, da dies katastrophal sein könnte. Ich habe einige Nachforschungen angestellt, hier , hier und hier , und sie alle sagen, dass sie keine privaten Methoden testen sollen. Ich kann das verstehen, denke ich, aber dann wie schütze ich mich vor der Entfernung dieser Codezeile ?
Wie Sie sehen, gibt die öffentliche Methode void zurück, sodass ich die Ergebnisse des öffentlichen Methodenaufrufs nicht testen kann. Und ich habe Komponententests, die ApplicationShouldBeInstalled() direkt testen.
BEARBEITEN - Ich ging damit auf JerKimballs Antwort.
Im Grunde benutze ich einfach ein Mock-Objekt (aus Moq) und vergewissere mich dann, dass seine Methode die erwartete Anzahl von Malen genannt wurde.
%Vor%Ich kann das nicht gehen lassen; Dieser Schnitt ist einfach hässlich. Obwohl ich eine tatsächliche Scheinklasse erstellen muss, ist diese Vorgehensweise viel sauberer:
Mock Implementierung:
%Vor%Testmethode:
%Vor%Hier ist eine mögliche Option ... gewährt, das ist sehr simpel, aber es könnte für Ihre Situation mit ein bisschen Änderung anwendbar sein;
Nehmen wir an, dass App wie folgt aussieht:
Und ApplicationShouldBeInstalled sieht folgendermaßen aus:
Sie könnten einen Komponententest schreiben, der "über erwartete Aktionen" bestätigt:
%Vor%Ich möchte sicherstellen, dass der Aufruf der privaten Methode nicht entfernt wird, weil das katastrophal sein könnte.
Das klingt, als sollte es einfach sein. Katastrophen sind ziemlich leicht zu erkennen. Führen Sie also einen Test aus, der die öffentliche Methode aufruft, und prüfen Sie, ob etwas Katastrophales passiert ist. Der Code innerhalb der privaten Methode, der gegen die Katastrophe geschützt ist, ist effektiv ein sichtbarer Nebeneffekt der Ausführung Ihrer öffentlichen Methode ... während die Tatsache, dass sie auf einen privaten Methodenaufruf zurückzuführen war, ein ist Implementierungsdetail .
In diesem Fall sollten Sie also grundsätzlich eine Anwendung erstellen, die nicht installiert werden sollte (aus welchen Gründen auch immer), und validieren, dass beim Aufruf von InstallApplications nicht
Ich dachte nur, ich würde ein bisschen Querdenken in den Mix werfen ...
Hören Sie auf, es versehentlich herauszunehmen, indem Sie es herausnehmen. :)
Selbst wenn Sie diese Methode öffentlich machen, können Sie nicht sehen, ob sie aufgerufen wurde oder nicht. Wenn man es öffentlich macht, würde man es testen können, aber nicht mehr.
Ihr Code wäre viel übersichtlicher, wenn Sie die Anweisung if regelmäßig verwenden würden. Ihr Zweck wäre sogar jenen Programmierern klar, die diese Zeile jetzt entfernen.
Sie können diese Methode auch verwenden, um einen Zähler beim Aufruf zu erhöhen. Komponententests können dann diesen Zähler testen.
Hinweis: Sie können diesen Counter internal machen und ihn für das Unit-Testprojekt mit InternalsVisibleToAttribute sichtbar machen.
AKTUALISIEREN
So könnte dieser Zähler implementiert werden:
%Vor%Testen Sie dann
%Vor%