Best Practice für die Integration von TDD in die Entwicklung von Webanwendungen?

Question

Unit-Tests und ASP.NET-Webanwendungen sind in meiner Gruppe ein unklarer Punkt.In den meisten Fällen bleiben gute Testpraktiken unberücksichtigt und Webanwendungen werden mehrere Jahre lang ohne Tests in Betrieb genommen.

Die Ursache für diesen Schmerzpunkt liegt im Allgemeinen in der Mühe, mitten in der Entwicklung eine UI-Automatisierung zu schreiben.

Wie integrieren Sie oder Ihre Organisation die besten TDD-Praktiken in die Entwicklung von Webanwendungen?

Answer 1

Unit-Tests sind möglich, wenn Sie Trennen Sie Ihre Schichten passend.Wie Rob Cooper angedeutet hat, Fügen Sie in Ihr WebForm keine andere Logik ein als die Logik zum Verwalten Ihrer Präsentation.Alle anderen Logik- und Persistenzebenen sollten in separaten Klassen aufbewahrt werden, die Sie dann einzeln testen können.

Einige Leute mögen es, die GUI zu testen Selen.Andere beschweren sich darüber, dass die Einrichtung mühsam sei.

Answer 2

Ich schichte die Anwendung und zumindest den Komponententest vom Präsentator/Controller (je nachdem, was Sie bevorzugen, MVC/MVP) auf die Datenschicht aus.Auf diese Weise habe ich eine gute Testabdeckung für den Großteil des geschriebenen Codes.

Ich habe mir FitNesse, Watin und Selenium als Optionen zur Automatisierung des UI-Tests angesehen, bin aber noch nicht dazu gekommen, diese in Projekten zu verwenden, also bleiben wir bei menschlichen Tests.FitNesse war das, zu dem ich tendierte, aber ich konnte dieses nicht so gut einführen wie TDD (macht mich das schlecht?Ich hoffe nicht!).

Answer 3

Das ist eine gute Frage, die ich auch abonnieren werde :)

Ich bin noch relativ neu in der Webentwicklung und schaue mir auch eine Menge Code an, der weitgehend ungetestet ist.

Für mich behalte ich die Benutzeroberfläche so leicht wie möglich (normalerweise nur ein paar Zeilen Code) und testen Sie alles andere auf Herz und Nieren.Zumindest kann ich dann einigermaßen sicher sein, dass alles, was in die Benutzeroberfläche gelangt, so korrekt wie möglich ist.

Ist es perfekt?Vielleicht nicht, aber zumindest ist es immer noch recht hoch automatisiert und der Kerncode (wo der Großteil der „Magie“ passiert) ist immer noch ziemlich gut abgedeckt.

Answer 4

Generell würde ich Tests vermeiden, bei denen ich mich auf UI-Elemente verlasse.Ich bevorzuge Integrationstests, bei denen alles von der Datenbankschicht bis zur Ansichtsschicht getestet wird (aber nicht das eigentliche Layout).

Versuchen Sie, eine Testsuite zu starten Vor Schreiben einer Zeile tatsächlichen Codes in einem neuen Projekt, da es später schwieriger ist, Tests zu schreiben.

Wählen Sie sorgfältig aus, was Sie testen – schreiben Sie nicht gedankenlos Tests für alles.Manchmal ist es eine langweilige Aufgabe, also machen Sie es nicht schwieriger.Wenn Sie zu viele Tests schreiben, besteht die Gefahr, dass Sie diese Aufgabe aufgrund der zeitaufwändigen Wartung aufgeben.

Versuchen Sie, so viele Funktionen wie möglich in einem einzigen Test zu bündeln.Auf diese Weise breiten sich die Fehler trotzdem aus, wenn etwas schief geht.Wenn Sie beispielsweise eine Digest-generierende Klasse haben, testen Sie die tatsächliche Ausgabe, nicht jede einzelne Hilfsfunktion.

Vertraue dir selbst nicht.Gehen Sie davon aus, dass Sie immer Fehler machen werden, und schreiben Sie Tests, um Ihr Leben einfacher und nicht schwieriger zu machen.

Wenn Sie sich beim Schreiben von Tests nicht gut fühlen, machen Sie es wahrscheinlich falsch ;)

Answer 5

Eine gängige Praxis besteht darin, so viel Code wie möglich aus dem CodeBehind in ein Objekt zu verschieben, das Sie isoliert testen können.Ein solcher Code folgt normalerweise den MVP- oder MVC-Entwurfsmustern.Wenn Sie nach „Rhino Igloo“ suchen, werden Sie wahrscheinlich den Link zum Subversion-Repository finden.Dieser Code ist eine Untersuchung wert, da er eine der besten MVP-Implementierungen auf Web Forms demonstriert, die ich je gesehen habe.

Wenn Sie diesem Muster folgen, führt Ihr Codebehind zwei Dinge aus:

1. Übertragen Sie alle Benutzeraktionen an den Präsentator.
2. Vom Präsentator bereitgestellte Renderdaten.

Unit-Tests des Präsentators sollten trivial sein.

Aktualisieren:Nashorn-Iglu finden Sie hier: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/

Answer 6

Es gab Versuche, die kostenlose UI-Automatisierung von Microsoft (in .NET Framework 3.0 enthalten) für die Arbeit mit Webanwendungen (ASP.NET) zu nutzen.Ein deutsches Unternehmen namens Artiso hat zufällig einen Blogeintrag geschrieben, der erklärt, wie man das erreicht (Verknüpfung).

Allerdings verlinkt ihr Blogpost auch auf einen MSDN-Webcast, der das UI Automation Framework mit WinForms erklärt, und nachdem ich mir das angeschaut habe, ist mir aufgefallen, dass man die AutomationId benötigt, um einen Verweis auf die entsprechenden Steuerelemente zu erhalten.In Webanwendungen verfügen die Steuerelemente jedoch nicht über eine AutomationId.

Ich habe Thomas Schissler (Artiso) danach gefragt und er erklärte, dass dies ein großer Nachteil von InternetExplorer sei.Er verwies auf eine ältere Technologie von Microsoft (MSAA) und hoffte selbst, dass IE8 dies besser machen würde.

Allerdings habe ich auch Watin ausprobiert und es scheint ziemlich gut zu funktionieren.Mir gefiel sogar Wax, das die Implementierung einfacher Testfälle über Microsoft Excel-Arbeitsblätter ermöglicht.

Answer 7

Ivonna kann Ihre Ansichten einem Unit-Test unterziehen.Ich würde dennoch empfehlen, den größten Teil des Codes in andere Teile zu verschieben.Einige Codes sind jedoch einfach gehört dort, wie Verweise auf Steuerelemente oder Steuerereignishandler.