Automatisiertes Testen und Silverlight
Silverlight ist inzwischen bei Version 4 angekommen und Microsoft bietet immer noch keine vernünftige Unterstützung für automatisierte Tests. Ja, ich weiß, es gibt das Silverlight Unit Test Framework aus dem Toolkit. Aber das ist, mit Verlaub, nicht praxistauglich. Dass Silverlight Code in der CoreCLR laufen muss und damit Unit Tests etwas aufwändiger zu realisieren sind, ist mir technisch völlig klar. Aber wieso drückt sich Microsoft davor, auf dem Gebiet seine Hausaufgaben zu machen? Wieso gibt es vom Hersteller selbst keine Unterstützung für Tests, die innerhalb von Visual Studio laufen? Wieso kann ich nicht per Knopfdruck einen einzelnen Test starten?
Die Arbeit mit Microsofts Silverlight Unit Test Framework ist lästig. Denn ich muss den Testrunner, der im Web-Browser läuft, mit Ctrl-F5 starten. Wenn ich mal Tests, mal die Silverlight Anwendung starten möchte, muss ich andauernd das Startpro
jekt ändern. Testgetriebene Entwicklung ist nur möglich, wenn ich einzelne Tests per Shortcut starten kann: einen Test schreiben, laufen lassen, rot. Implementieren, Test erneut laufen lassen, grün. Nächsten Test schreiben… Das alles geht nicht, solange der Testrunner im Browser läuft. Und wenn sich dann beim Start des Testrunners erst noch ein Popup öffnet, welches 5 Sekunden darauf wartet, ob ich möglicherweise nur Tests mit einem bestimmten Tag starten möchte, weiß ich, dass dieses Werkzeug definitiv nicht für die testgetriebene Entwicklung entworfen wurde. Schade.
Weiterhin halte ich es für sehr bedenklich, dass die Community sich nicht rührt. Wie testet ihr euer Silverlight Zeugs denn automatisiert? Garnicht?
Sorry für mein Lamentieren… aber ich verfolge das Thema nun schon seit Silverlight 1.1. Und seitdem hat sich nichts nennenswert verändert. Oder habe ich was übersehen?
Tags: Silverlight
May 11th, 2010 at 16:15
Ich finde es Bedenklich, wenn der Test-Runner im Browser läuft. Da frage ich mich direkt: Wie läuft der im Build-System? Geht da ein Browser auf? Gibts keine Konsolen-Anwendung?
Aus meiner aktuellen Erfahrung mit GWT kann ich sagen: Das ist sehr schade. Denn mit GWT-Code geht das. GWT-Codeist Java, das nach Javascript übersetzt wird. Bei Einsatz entsprechender Ansätze (SRP, Entkopplung) kann man den Code als reine Java-Unit-Tests laufen lassen. Alternativ bietet GWT aber auch eine Simulation für Unit-Tests an, die nicht ohne GWT-Controls auskommen.
Eigentlich nicht zu verstehen, warum Microsoft das nicht auch schafft. Strukturierung und Unit-Testen im UI Bereich scheint wohl nicht Massentauglich zu sein?
May 12th, 2010 at 6:40
die Frage ist: Wer braucht das? Offensichtlich nicht ganz so viele. Ich sehe automatisierte Tests von UI generell sehr skeptisch. Noch viel skeptischer im Silverligth Umfeld. Silverligth ist von der Idee her eher für den APP Ansatz geeignet. Sieht schick aus, ist schnell implementiert, hat sehr kurzen Lebenszyklus. Vor allem aber lebt eine Silverlight Anwendung in einem komplexen Umfeld. OOB oder nicht OOB, Inet oder nicht Inet, Windows oder Mac, Elevated privilages oder nicht. Touch, Tablet oder ebene nicht. Schnelles Inet langsames, Proxys usw. All das lässt sich nur mit imensen Aufwand testen und übersteigt den Entwicklungsaufwand bei weitem.
PS: Silverlight Tools sind noch nicht Final: es wird sich beim Starten noch eine Kleinigkeit verbessern.
May 12th, 2010 at 6:55
@Hannes Ich bezog mich hier gar nicht auf die UI Tests. Die gehen mit dem MS Toolkit Zeugs ja ganz gut. Und wer Controls implementiert ist froh, wenn er auf automatisierte UI Tests zurückgreifen kann. Ich bezog mich eher auf Tests unterhalb des UI. Wenn ich ein BoxPlot Control implementiere, muss ich Median und Quartile berechnen. Das sollte getestet werden, oder?
Was ich nicht verstehe, ist das Argument, bei APPs (was auch immer das genau ist) müsse nicht automatisiert getestet werden. Denn ich glaube, wir sind uns einig, dass auch die getestet werden. Aber warum nicht automatisiert?
May 12th, 2010 at 7:05
früh am Morgen
APPs sind Exemplarisch das Zeugs das es in 150.000 Stück für das IPhone gibt.
Ich hab etliche Bugs als Beispiel die mit automatisierten Tests nicht gefunden werden. Letztens zb ein Zertifikat das 2 Tage nach Rollout abgelaufen ist. Aus der Vergangenheit der klassisker Anwendungen dir nur bis zum 12ten laufen. Mit den komplexen asynchronen UIs von Silverlight wird das noch wesentlich herausfordernder. Ich denke das Unit Tests hier generell zu wenig bieten, beobachte aber interessiert was unsere Kunden in dem Umfeld treiben und aktuell schreibt keiner Tests.
May 12th, 2010 at 7:44
@Hannes Ich glaube, wir sind gar nicht so weit auseinander. Volle Zustimmung, dass nicht alle Bugs durch automatisierte Tests gefunden werden. Die spielen ihren Vorteil (mindestens) bei Regressionsproblemen aus. Wichtig ist mir, Unit Tests und Integrationstests auseinander zu halten. Denn ich will natürlich nicht nur Unit Tests automatisieren, sondern auch Integrationstests.
Dass derzeit “keiner Tests” schreibt ist ja auch meine Beobachtung. Na ja, nicht wirklich keiner, aber zu wenige.
Und noch mal zu den APPs. Wenn die möglichst schnell durch die Tür müssen und dann auch nur eine kurze Lebensdauer haben, ist das doch eher ein Argument FÜR automatisierte Tests, oder? Wir haben doch in der Situation gar nicht die Zeit, die Tests manuell durchzuführen. Die spannende Frage ist, welche Architektur, welche Technologie, welche Werkzeuge unterstützen diese Art von Programmen am besten?
May 12th, 2010 at 18:48
Evtl. hier posten / voten / Leute motivieren, zu voten:
http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions