Mein Chef möchte, dass ich eine ASPX-Seite mit Textfeldern zur Vereinfachung der Eingabe von Kreditkarteninformationen erstelle, damit wir einige Methoden unseres CreditCard-Dienstes testen können.
Das ist in Ordnung, aber ich würde denken, wir könnten einen Unit-Test dafür machen. Die einzige Sache ist, anstatt die Sachen in ein Webformular einzugeben, würden wir nur die Variablenwerte ändern, die in den Komponententest übergeben wurden.
Kann mir jemand sagen, ob wir verrückt sind, statt einer ASPX-Seite einen Komponententest zu machen, um Testdaten zu testen und einzugeben, um einige Aufrufe einiger unserer Methoden zu testen?
Er wird mir am Ende sagen, dass der Komponententest zu viel Zeit in Anspruch nimmt (ich habe versucht, ihm zu sagen, dass wir Unit-Tests durchführen müssen), was eine lahme dumme Entschuldigung ist.
Ich fühle mich ein bisschen schuldig, weil ich so eine glatte Antwort hinterlassen habe, also hier ist eine ernstere Meinung:
Sehen wir uns an, was es kosten würde, um den Dienst zu testen. Ein echter Komponententest ist ein automatisierter Test, der eine einzelne Einheit testet (in Ihrem Fall wäre dies der Webdienst ohne Backend-Systeme wie Datenbanken usw.). Wie andere darauf hingewiesen haben, ist in diesem Fall wahrscheinlich ein ordnungsgemäßer Komponententest des Dienstes zu spät.
Das bedeutet nicht, dass Sie ein Einheitentest -Framework (wie MSTest, xUnit.net, NUnit usw.) nicht verwenden können, um Ihre Servicetests zu steuern. Lassen Sie uns das das Szenario zur Entwicklung einer Wegwerf-Aspx-Seite kontrastieren:
Was ist also anders?
Zusammenfassend würde ich sagen, dass Sie besser dran sein sollten, wenn Sie in diesem Fall nicht darauf bestehen, echte Komponententests durchzuführen, sondern einfach ein Unit-Testing-Framework für automatisierte -Tests verwenden mit den automatisierten Tests als mit der ASPX-Seite. Der Entwicklungsaufwand wird mehr oder weniger derselbe sein.
Für Ihr nächstes Projekt können Sie dann sehen, ob Sie TDD von Anfang an verwenden können, aber das ist ein weiterer Kampf.
Viel Glück.
Sie sind verrückt, wenn Sie nicht Ihren Webservice testen, statt einen manuellen Prüfkabelbaum zu schreiben:)
Grundsätzlich ist ein Webservice eine API, auf die über ein Remote-Protokoll zugegriffen wird. Warum also nicht Unit-Test?
Wenn es sich um einen ASMX-Webdienst handelt, können Sie versuchen, das HttpPost-Protokoll in Ihrer Web.config zu aktivieren:
%Vor%Dadurch wird das Testformular für den Webdienst aktiviert, wenn Sie die ASMX-Seite in Ihrem Browser aufrufen. Es funktioniert möglicherweise nicht gut für komplexe Typen. Wenn Sie jedoch komplexe Typen haben, ist es einfacher, Unit-Tests als ein benutzerdefiniertes Formular zu erstellen.
Das Argument, dass Komponententests schwieriger sind als ein Webformular, scheint falsch zu sein. Wenn Sie ein Formular entwickeln, müssen Sie den Webdienst-Client-Code trotzdem schreiben, zusätzlich zum Erstellen der Seite selbst.
Ihr Chef möchte vielleicht bestätigen, dass der Web-Service von einer ASPX-Seite aufgerufen werden kann und einige Werte ausprobieren kann. (Möchte er beispielsweise einen Code aufrufen, den ein anderer Benutzer zum Erstellen der echten Webseite verwendet?) Wenn Ihr Web-Service externe Dienste aufruft und / oder eine Datenbank verwendet, wird es ohnehin schwierig sein, automatische Komponententests dafür zu schreiben.
>Was das Schreiben eines echten Komponententests für den Webservice betrifft, so denke ich, dass Sie dieses Mal schon den Kampf verloren haben ....
Versuchen Sie das nächste Mal, Komponententests für jede Methode zu schreiben, die die Webdienste gerade vor oder nach dem Schreiben der Methode aufrufen. Es besteht keine Notwendigkeit, Ihrem Chef zu sagen, dass Sie dies tun, da dies dazu führen wird, dass Arbeitscode schneller produziert wird.
Sobald Sie die Komponententests bewiesen haben, helfen Sie Sie schneller Code zu schreiben, können Sie versuchen, Test Driven Development einzuführen und / oder die Komponententests in den Quellcode einchecken lassen Kontrollsystem und andere Leute führen sie aus, wenn sie den Code ändern.
Du könntest immer etwas von deiner eigenen Freizeit verbringen, wenn dein Chef nach Hause gegangen ist und versucht hat, die Unit-Tests zu schreiben. Dann sag ihm nur, was du getan hast, wenn er fragt, warum dein Code keine Bugs enthält.
Es ist ein Kampf, den Sie sicherlich verlieren werden. Sie müssen sich in Ihre Chefschuhe stecken. Es gibt Projekte, bei denen das Komponententesten zu viel Zeit in Anspruch nehmen könnte, besonders am Ende des Entwicklungszyklus, wenn alles fertig ist. TDD muss von Anfang an verfolgt werden oder Sie werden zu viel Zeit verlieren, wenn Sie Komponententests durchführen, nachdem Sie bereits vergessen haben, wie ein bestimmter Code funktioniert (nein, Kommentare sind normalerweise nicht genug).
Machen Sie es einfach für die nächsten Projekte, die Sie TDD tun. Nachdem Sie alle Ihre Code-Einheit getestet haben, können Sie eine Art von Funktionstests mit Tools wie JMeter und Selenium .
Stattdessen können Sie einen einfachen .NET (oder Java) -Test schreiben, der den Web-Service aufruft und verschiedene Szenarien prüft, zusammen mit dem offensichtlichen Vorteil (es ist testbar), Sie haben auch eine automatisierte Möglichkeit, seine Funktionalität zu überprüfen.
>Die Zeit, die beim Schreiben der Komponententests verschwendet wird, wird durch die Zeit, die beim wiederholten Testen des gleichen Szenarios eingespart wurde, wiederhergestellt, anstatt nur die automatisierten Tests auszuführen.
Wenn Ihr Chef nicht von diesem Punkt überzeugt ist, dass er zu Studien führt, die zeigen TDD / Unit Tests Wirksamkeit .
Wenn alles andere fehlschlägt, warum nicht ein automatisches Tool wie soapUI verwenden, dann ersparen Sie sich zumindest das manuelle Testen der gleichen Funktionalität und immer wieder.
Denke, dass du den Kampf bereits verloren hast (wir fühlen für dich). Es gibt bessere Lösungen als das manuelle Erstellen eines Consumers für Ihren Webdienst.
Besuche SoapUI . Es verbraucht Ihre WSDL und lässt Sie mit den XML-Anfragen spielen. Sehr einfach in einen Web-Service einstecken, um es auszuprobieren, wenn alles, was sie wollen, ein POC ist.
Meiner Meinung nach, wenn Sie ASPX-Seite erstellen und Wert aus Webformular erhalten, wäre es mehr Echtzeit-Tests als Komponententests. Ich hoffe, der Webservice wurde bereits von der Organisation getestet, die Ihnen diesen Webservice zur Verfügung stellt. Ich denke, Sie müssen nur ASPX-Formular erstellen und Ihre Arbeit erledigen.
Sie können Komponententests für Ihre gesamte Entwicklungsprozesszufriedenheit durchführen. Es ist eine gute Idee, dass der Komponententest von der Person durchgeführt werden sollte, die den Code der Klasse / Funktion / Web-Methode geschrieben hat.
Lass es mich wissen, wenn du irgendeine Frage hast.
Tags und Links c# unit-testing web-services