Was ist das am meisten gepflegte neueste Framework in .NET zum Schreiben von Akzeptanztests? [geschlossen]

Wir haben gerade angefangen, FitNesse zu verwenden, und bisher bin ich mit der Entscheidung zufrieden. Ein sehr kurzer Überblick:

1. Sie schreiben Ihre Tests in einem Wiki.
2. Sie schreiben ein 'test fixture' Modul (welches eine c # Assembly sein kann) stellt die Brücke zwischen den "Tests" im Wiki und dem SUT (System unter Test).
3. Wenn Sie die Tests ausführen, verwendet die FitNesse-Engine Reflektion, um die Wiki-Tests in Aufrufe Ihrer Test-Fixture-Assembly zu übersetzen, die wiederum das SUT aufruft. Die Rückgabewerte werden an das Wiki zurückgegeben, damit Sie sie "bestätigen" können.

Die öffentliche Schnittstelle des Testbefestigungscodes ist die Sprache, mit der Sie Tests im Wiki schreiben. Ich bin mir nicht sicher, ob ich das sehr gut erklärt habe, aber es gibt reichlich Ressourcen und Videos im Internet. Ich empfehle dieses von Bob Martin, Autor von FitNesse.

Ich habe FitNesse aus verschiedenen Gründen gewählt:

• gut etablierter Rahmen
• funktioniert mit .NET mit dem FitSharp-Plugin: Ссылка
• weil die Tests im Wiki in der Sprache geschrieben sind, die du in deinem Fixture Code definierst, sind sie lesbar
• Tests können über die Befehlszeile aufgerufen werden, die wir für Continuous Integration benötigen.
• Robust 1: Wenn sich die Schnittstelle des SUT ändert, müssen Sie nur den Testbefestigungscode ändern, nicht die Tests
• Robust 2: Wir testen nicht auf der Ebene der flüchtigen Benutzeroberflächen.

Es braucht etwas Zeit, um sich daran zu gewöhnen, aber ich finde es viel zuverlässiger als unser derzeitiges Testkonzept über die Benutzeroberfläche. Wir machen dies derzeit in einer Home-Brew-Anwendung, bei der zuvor aufgezeichnete UI-Aktionen abgespielt und Screenshots verglichen werden. Wenn die Tests rot sind, ist es selten, weil das SUT tatsächlich gebrochen ist. In der Regel haben wir Timing-Probleme, da UI-Steuerelemente nicht sofort reagieren. Daher müssen Verzögerungen zwischen den UI-Aktionen eingebaut werden. Dies bedeutet, dass die gesamte Testsequenz über Nacht abgearbeitet wird.

mSpec (Maschinenspezifikationen) ist ein TDD / BDD-Framework, das sehr beliebt ist.

nUnit ist ein Unit-Test-Framework (welches auch für Akzeptanztests verwendet werden kann ).

Bitte betrachten Sie Ranorex als eines von ziemlich neuen Tools.

Ссылка

Sie machen einen tollen Job, indem sie einen kompletten Werkzeugsatz inklusive Unit-Test-API, Automation Engine und einem Testrekorder zur Verfügung stellen. Kurz gesagt - Sie schreiben Ihre Tests in C # oder Sie "notieren" sie mit dem Rekorder und der Rekorder schreibt sie als C # -Code.

Dann antworten Sie ihnen und führen Ihren C # -Code aus. Sie erstellen so viele Bestätigungen, wie Sie möchten, und mit der Automatisierungs-API können Sie alles, was auf dem Bildschirm sichtbar ist, automatisieren.

Tolles Werkzeug für ATDD, wir benutzen es seit einiger Zeit und wir sind zufrieden.