Warum sollten wir codiertes UI verwenden, wenn wir Specflow haben?

8

Wir haben Specflow und WatIn für Abnahmetests bei meinem aktuellen Projekt verwendet. Der Kunde möchte, dass wir stattdessen Microsoft-coded-ui verwenden. Ich habe nie ui getestet, aber von dem, was ich bisher gesehen habe, sieht es umständlich aus. Ich möchte meine Akzeptanztests vorab angeben, bevor ich ein UI habe, nicht als Ergebnis einiger Aufnahme- / Wiedergabestücke. Wie auch immer, kann mir bitte jemand sagen, warum wir die Specflow / watin-Combo wegwerfen und durch codierte ui ersetzen sollten?

Ich habe auch gelesen, dass Sie specflow mit codierten ui kombinieren können, aber es sieht für viele Dinge, die ich bereits in specflow ausprobiere, wie viel Aufwand aus.

    
Marius 17.08.2011, 06:01
quelle

1 Antwort

10

Ich habe einen Blogbeitrag verfasst, wie Sie das tun könnten, was Sie nützlich finden könnten

Ссылка

Die Pro und Kontra von Coded UI Test, die ich mir vorstellen kann, ist das Testen der Anwendung genau, wie der Benutzer es verwenden wird. Dies ist gut für den Akzeptanztest, hat aber auch seine Grenzen. Es ist auch sehr gut für End-to-End-Tests. In der Vergangenheit waren UI-Tests als fragil bekannt. Wenn beispielsweise MS die VS2010-Benutzeroberfläche erstellt hat, sind fast alle UI-Tests fehlgeschlagen. Der Hauptgrund dafür ist der Technologiewandel. Codierte UI-Tests helfen dabei, dies zu verhindern, indem sie mit einem Steuerelement übereinstimmen. Es verwendet mehr eine Wahrscheinlichkeitsbasierte Übereinstimmung. Dies bedeutet, dass es versuchen wird, die beste Übereinstimmung basierend auf den Informationen zu finden, die es hat, wie etwa den Kontrollnamen. Für uns waren Coded-UI-Tests unsere Wahl aufgrund von Technologieeinschränkungen. Unsere Legacy-App ist VB und obwohl CUIT nicht gut funktioniert, bin ich gerade dabei, eine Erweiterung zu schreiben, um bessere Kontrollinformationen zu bekommen. Es war immer noch unsere einzige Wahl. Bedenken Sie auch, dass CUIT neu ist und seine eigenen Einschränkungen hat. Sie sollten darauf vorbereitet sein, Ihr Projekt so zu strukturieren, dass Ihre UIMaps aufgrund des aktuellen Ende-zu-Ende-Verhaltens in VS2010 ein wenig manuell bearbeitet werden können, z. B. das Erstellen eines CUIT aus einer vorhandenen Aktionsaufzeichnung Der Test in einer UIMap namens UIMap.uitest. Es gibt keine Möglichkeit, diese zu ändern oder auf eine andere UIMap zu übertragen. Wenn Sie mehrere Karten verwenden, bedeutet dies, dass Sie Ihre Schritte zuerst aufzeichnen und dann in Ihrem Test verwenden müssen. Aber in .net ist es immer noch sehr flexibel.

Bei weitem das Beste an specflow ist die Gerkin-Syntax für Lesbarkeit und lebendige Dokumentation. Normalerweise zielt Ihre Testfunktion oder das Verhalten Ihrer App darauf ab, wo der Wert herkommt. Im Allgemeinen richtet sich der Test direkt unter der Benutzeroberfläche. Es gibt eine etwas geringere Chance, dass der Test bricht, wenn sich die Benutzeroberfläche hier aber ändert. Specflow ist für mich großartig, wenn Ihre Anwendung ständig geändert wird und Sie sicherstellen möchten, dass vorhandene Funktionen weiterhin funktionieren. Es passt auch gut in eine Scrum-Umgebung, wo Sie Ihre Szenarien als eine Beschreibung darüber schreiben können, wie es funktionieren soll. Eine Beschränkung auf Specflow, die ich sehen kann, ist offen für die Interpretation. Aus diesem Grund kann es leicht sein, einen Test zu schreiben, der nicht sehr wiederverwendbar und schwer zu warten ist. Ich verwende gerne allgemeinere Begriffe, um meine Schritte wie "Anmeldung als Benutzer1" anstelle von "Gehe zur Anmeldeseite, Eingabe von Benutzername und Passwort, Klick auf Login" zu beschreiben. Wenn Sie es granularer beschreiben, wird es schwieriger, es erneut zu verwenden, wenn Sie es eng an die Benutzeroberfläche koppeln. Wie der Login tatsächlich funktioniert, sollte der Code hinter der Specflow-Funktion sein.

Die Kombination der beiden mit uns scheint jedoch vorteilhafter zu sein, als nur codierte UI-Tests zu verwenden. Wenn wir uns dazu entschließen, die Benutzeroberfläche vollständig zu ändern, würden wir zumindest die Verhaltensweisen, die in unseren specflow-Funktionen erwartet werden, auf eine Weise bereitstellen, die jeder verstehen kann. Am Ende müssen Sie überlegen, wie sich die Anwendung entwickelt und welche Art von Anwendung es gibt.

    
Ryan Burnham 19.08.2011 04:38
quelle

Tags und Links