Frage

Wir arbeiten hier in Visual Studio 2008 an einem Projekt. Wir verwenden die mit IT bereitgestellte integrierte Testsuite (Microsoft.visualstudio.TestTools.unittesting Namespace). Es stellt sich heraus, dass so viel zu unserem Leidwesen viel Komplexität (und damit Fehler) in unsere UI -Schicht codiert sind. Während unsere Unit -Tests eine angemessene Aufgabe haben, unsere Geschäftsschicht abzudecken, ist unsere UI -Schicht eine ständige Quelle der Reizung. Wir würden das idealerweise auch gerne testen. Kennt jemand eine gute "Microsoft-kompatible" Art, dies in Visual Studio zu tun? Wird es eine Art Konflikt einführen, um Unit -Test -Frameworks wie zu mischen? Nunitforms Mit dem Microsoft? Gibt es offensichtliche Bärenfallen, die ich mit Einheiten-Test-Formularen bewusst sein sollte?

War es hilfreich?

Lösung

Sie müssten die Benutzeroberfläche neu aufstellen, damit die Benutzeroberfläche keine Einheitentests benötigt. Die Benutzeroberfläche sollte eine minimale oder keine Geschäftslogik enthalten. Es gibt viele Muster, die sich mit diesem Problem befassen. Martin Fowler hat einen sehr guten Artikel, der viel über diese Muster erklärt: http://martinfowler.com/eaadev/uiarchs.html

In dem Refactoring -Buch von Martin Fowler gibt es ein kleines Kapitel, in dem sich das Refactoring der nicht überprüfbaren Benutzeroberfläche spricht. Sie können auch effektiv mit dem Legacy -Code arbeiten.

Hinweis: Es gibt Tool, mit dem die UI -Tests automatisiert werden können. SilkTest kommt mir in den Sinn. Aber ich würde sie nicht benutzen, wenn möglich.

Andere Tipps

Dies ist alles gut und gut für regelmäßige Anwendungseinheiten -Tests ... aber wenn Sie Benutzersteuerungen erstellen, die Unit -Tests für das Kontrollverhalten und die Zustände benötigen, benötigt es auch ein Unit -Test -Framework. Nunitforms sind möglicherweise die Antwort für Sie - persönlich muss ich es mir selbst überprüfen.

Ich benutze die Passive View Architecture, wie hier detailliert http://martinfowler.com/eaadev/passivescreen.html

Verschieben Sie im Grunde genommen Ihren gesamten Code in den Formularen in eine separate Klasse, die als XXXUI bezeichnet wird. Das Formular implementiert dann eine IXXXUI -Schnittstelle und enthüllt alles, was die XXXUI -Klasse benötigt. Sie können wahrscheinlich die Dinge vereinfachen und mit mehreren Steuerelementen zu einer Methode zusammenarbeiten.

Der Fluss wird dann auf eine Schaltfläche klicken. Die Taste ruft eine Methode in der entsprechenden UI -Klasse auf. Übergeben alle benötigten Parameter. Die UI -Klassenmethode verändert das Modell. Verwenden Sie dann die Benutzeroberfläche die Benutzeroberfläche.

Für Unit -Tests haben Sie Test- oder Dummy -Klassen implementieren die Schnittstellen und registrieren sich bei den UI -Klassen. Sie können diese Testklassen jede Art von Eingabe ausführen und entsprechend reagieren. Normalerweise habe ich Sequenzlisten, die in einer genauen Reihenfolge das tun. (Tippen Sie auf ein, klicken Sie auf diese, scrollen Sie das, geben Sie dann B usw. ein).

Es ist ziemlich einfach, WinForms mit Zulassungsstests (www.upityests.com- oder nuget -Zulassungstests) zu testen, und sie sind sowohl mit MStest als auch mit Nunit kompatibel.

Hier gibt es ein Video, wie es geht: https://www.youtube.com/watch?v=hKEKBJOSFJ8

Aber der Prozess ist einfach. 1) Erstellen Sie das Formular, das Sie in dem von Ihnen gewünschten Zustand testen möchten. 2) winFormapprovals anrufen.Verify (Formular)

Zulassungsstörungen verwendet das Golden Master Paradigma, um das Ergebnis zu erfassen. Wenn Sie es mögen, benennen Sie die Datei einfach in. Genehmigt und der Test wird bestehen.

Das Tolle daran, dass Sie vorhandenen Code refactoring Code refactorieren, müssen sich nicht einmal Sorgen darüber machen, was das Ergebnis ist, da Sie nur besorgt sind, dass Sie ihn nicht ändern.

Schauen Sie sich Jeremy D. Millers WIP an Präsentationsmuster Wiki -Seite für die Refactoring Inspiration :)

Miller schreibt ein Buch und es sieht so aus, als würde es ein Muss für solche Dinge sein.

Ich habe Nunitforms verwendet, wenn es darum geht, meine eigenen UI -Steuerelemente mit guten Ergebnissen zu testen! Ich würde den anderen beim Refactoring zustimmen, wenn Sie Standard (oder gut getestete) UI -Steuerelemente verwenden.

Wenn der Fokus darauf liegt, die tatsächlichen Steuerelemente zu testen, würde ich Nunitforms verwenden, da es erweitert werden kann, um Ihre neuen Steuerelemente zu unterstützen. Wenn Sie keine manuellen Tests einbeziehen möchten, benötigen Sie eine LIB, die die "bildbasierte" Analyse des angezeigten Endergebnisses durchführen kann.

Ich habe es mit testComplete dafür ausprobiert, aber ich war ein bisschen zu teuer, da ich eine ähnliche Bibliothek für nur den Bildvergleich in C#codieren konnte. Mein Plan wäre also, die Steuerelemente getrennt zu testen und die Benutzeroberfläche wie erwähnt, wie ich die anderen erwähnt hat.

Sie sollten die Microsoft -codierte UI verwenden, um die UI -Ebene zu testen. Dies beinhaltet das Schreiben (oder Aufzeichnen) von Tests, bei denen Aktionen nachahmen, die ein Benutzer ausführen und durchführen würde, um Anweisungen zu vermitteln, um sicherzustellen, dass die korrekte Ausgabe erzielt wird.

Dies ist natürlich nicht in Unit -Tests, da es schwierig ist, Aktionen aus dem Frontend zu erstellen, die eine einzelne Arbeitseinheit testen und kein Ersatz für andere Unit -Tests sind. Ich bin auch damit einverstanden, dass die Geschäftslogik vorne wie möglich dünn sein sollte. Dies füllt jedoch alle Lücken, bei denen Ihre Unit -Tests nicht abdecken. Hoffentlich werden nur kleine Arbeitseinheiten nicht durch Ihre Unit -Tests abgedeckt, sodass die codierten UI -Tests die verbleibenden nicht getesteten Einheiten fangen.

Die codierte UI ist mit den neuesten Versionen von Visual Studio Premium eingebaut. Ich schlage vor, dass Sie nicht nur die Aufzeichnungsfunktionen verwenden, sondern stattdessen lernen, wie Sie die Tests selbst schreiben, da dies Ihnen eine größere Flexibilität bietet.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top