Ich versuche den besten Weg zu finden, Nachrichtenboxen von meiner Logik zu entkoppeln, damit ich sie richtig kombinieren kann. Jetzt habe ich mich gefragt, ob es genug wäre, wenn ich gerade eine separate Helferklasse (C #) machen würde, die ich später für meine Nachrichtenbox stumm machen kann. Zum Beispiel:
%Vor%Dann würde ich jedes Mal, wenn ich eine Nachrichtenbox verwenden müsste, stattdessen messageboxHelper / msgBoxAlg (...) anstelle von messagebox.show (...) verwenden. Mit der Bool Show konnte ich sie während des Tests aktivieren oder deaktivieren.
Ich frage mich nur, ob das der richtige Weg ist. Womit meine ich, gibt es einen leichteren oder besseren Weg, das richtig zu machen? Ich kann die Nachrichtenboxen nicht einfach ablegen, sie geben "wichtige" Informationen an den Benutzer weiter ("Wollen Sie dieses Fenster schließen?" JA / NEIN etc.). Es könnte auch nur sein, dass ich nicht die richtige Software-Entwicklung verwende, und ich sollte meine Messageboxen von meiner Businesslogik mehr abkoppeln?
Ja, es ist der richtige Weg. Aber statt der statischen Klasse sollten Sie IDialogService implementieren und in Klassen einfügen, die Dialoge anzeigen sollten:
Beim Testen von SomeClass sollten Sie das Mock-Objekt von IDialogService anstelle von echtem% injizieren.
Wenn Sie mehr Benutzeroberflächenlogik testen möchten, sollten Sie das MVVM -Muster verwenden.
Sehen Sie sich Inversion of Control (IoC) an, der grundlegende Grundsatz lautet, dass Dinge, die Aktionen ausführen, als Schnittstelle übergeben werden sollen. Anschließend binden Sie einen IoC-Container an die Schnittstellen zu bestimmten Implementierungen für Ihre App. Um dies in Ihrem Fall leicht zu erreichen, übergeben Sie das, was Nachrichtenfelder als Schnittstelle enthält, und erstellen Sie in Ihrem Unit-Test eine gefälschte Version dieses Nachrichtenbox-Dienstes, der kein Nachrichtenfeld anzeigt.
Sehen Sie Ссылка für Details zu IoC, mein Lieblingscontainer ist Ninject (http://ninject.org)
Idealerweise möchten Sie, dass der Code, den Sie mit Komponententests testen, logisch und nicht UI ist. Daher sollte die Logik Ihres Tests nicht wirklich sein, ein Meldungsfeld anzuzeigen. Wenn Sie die Benutzeroberfläche testen möchten, würde ich Ihnen Tests für codierte UI vorschlagen.
> Nach Ihrer Frage zu urteilen, würde ich mir vorstellen, dass Ihr Code nicht wirklich ein MessageBox verwenden sollte. Vielleicht sollten Sie stattdessen einen Callback oder eine beliebige Action oder die von Luke McGregor und Sergey V erwähnten Ansätze verwenden.
"Einheitstest" ist in seiner genauen Bedeutung ein Test des atomaren Verhaltens. Dies ist nicht die einzige Art von Code-gestützten Tests, die Sie für Ihren Code durchführen können. Insbesondere für längere Szenarien mit "Ja / Nein" -Dialogen, die Sie erwähnen, sind größere Code-gestützte Tests oft effektiver als Unit-Tests.
Um jedoch einfacher schreiben zu können, wäre es gut, nicht nur einen speziellen Dienst zu erstellen, wie er von Sergii erwähnt wurde, sondern auch asynchron zu telefonieren:
%Vor%Wenn Sie Meldungsfelder in nicht asynchrone Serviceaufrufe einbetten und sich über sie lustig machen, fangen Sie bei längeren Szenarien an, dem "Arrange-Act-Assert" -Muster zu widersprechen, indem Sie Benutzeraktionen vorhersagen, bevor sie tatsächlich stattfinden (statt "Act "), was zu zahlreichen Problemen beim Testen führen kann, insbesondere wenn Ihre Tests mit BDD / SpecFlow durchgeführt werden. Wenn diese Aufrufe asynchron ausgeführt werden, können solche Probleme vermieden werden. In meinem Blog-Artikel finden Sie Details und Beispiele für Tests in größeren Mengen mit Messageboxen.
Tags und Links c# unit-testing messagebox