Mittwoch, 2. Mai 2007
Wer sind wir?
Vielleicht nicht ganz so offensichtlich: Die Autoren dieses Blogs gehören zu it-agile.
Freitag, 27. April 2007
Spontanvortrag Model-View-Presenter von Johannes Link
Nachdem Johannes am Montag krank war und den Powerworkshop nicht mit Informationen zum Model-View-Presenter versorgen konnte (und dann am Dienstag in seiner Session auch nicht genug Zeit dafür war), habe ich ihn genötigt, uns doch mal an unserem Flipchart am Stand einen Model-View-Presenter-Vortrag zu halten.
Das war sehr interessant, denn mittels Model-View-Presenter schafft man genau die richtigen Abstraktionen, um möglichst große Anteile auch der Oberfläche testbar zu halten und die eigentliche View mit technischen Abhängigkeiten sehr klein und ohne Fachlogik zu gestalten.
Nähere Infos zu Model-View-Presenter bei Martin Fowler:
http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
(Nicht erschrecken, er hat da jetzt 2 Pattern draus gemacht, Johannes hat das vorgestellt, das Fowler jetzt Passive View nennt: http://www.martinfowler.com/eaaDev/PassiveScreen.html)
Vielen Dank, Johannes!
Donnerstag, 26. April 2007
Selenium
Der Vortragende Neal Ford ist von ThoughtWorks, der Vortrag auf englisch.
Selenium ist ein funktionales Open-Source Testtool für Webanwendungen, geschrieben in JavaScript.
Man schreibt die Tests ähnlich wie bei FIT-Action-Fixtures auf. Ausgeführt wird der Test im Browser. Dabei wird alles mögliche unterstützt, z.B. auch Popup-Fenster.
Im Test muss man natürlich die Elemente auf der HTML-Seite adressieren. Das geht über IDs und Namen und den DOM. Letzteres braucht man vor allem für Elemente, denen man keine IDs gibt, wie z.B. Ausgabetabellen.
Es gibt ein Firefox-Plugin namens XPather: Damit clickt man auf ein Element auf der Seite und bekommt den DOM-Pfad angezeigt, den man dann in den Test einpasten kann.
Bei der String-Prüfung werden auch Wildcards und Regexps unterstützt.
Das Adressieren der Elemente und die Prüfung der Seiteninhalte ist also sehr flexibel.
AJAX geht auch.
Es gibt ein paar Geschichten, die doch nicht gehen: z.B. wenn man in Java-Script als Reaktion auf onload einen Dialog öffnet. File-Upload funktioniert nur in Firefox.
Variablen werden unterstützt. So kann man einen Wert, den die Anwendung generiert, in einer Variablen starten und woanders wieder einfügen. Variablenwerte kann man auch durch JavaScript berechnen lassen.
Der Referent rät dazu, hart-codierte Werte in Akzeptanztests zu vermeiden. Ich habe aber nicht verstanden, wie er die umgeht.
Selenium lässt sich in automatic-builds integrieren. Dazu muss man anscheinend nur den Browser mit der URL des Tests aufrufen. Ich bin nicht ganz sicher, aber es scheint so, dass Selenium das Ergebnis dann an den Integration-Server POSTet.
Normalerweise muss man die Anwendung zum Testen serverseitig mit dem Browser-Bot starten. Mit Remote-Control-Selenium braucht man das nicht und kann so Seiten testen, die dafür nicht vorbereitet sind (z.B. Google). Das läuft über einen Proxy-Server. Damit kann man nicht nur die Tests ausführen, sondern auch über die Kommdozeile die Web-Anwendung fernzusteuern. Also kann man die Selenium-Tests auch als JUnit-Tests oder in Ruby oder sonstwas schreiben. Jetzt zeigt er einen Selenium-Test in JUnit. Das sieht eher unübersichtlich aus - die HTML-Version des Tests ist übersichtlicher. Vielleicht helfen beim JUnit-Test auch ein paar Extract-Methods.
"Web Developer Toolbar"-Plugin für Firefox und Internet-Explorer ist nützlich.
Es gibt eine Selenium-IDE als Firefox-Plugin. Damit kann man Tests aufzeichnen und wieder ausführen. In dem Test gibt es natürlich kaum Asserts. Die fehlenden Asserts kann man direkt in der IDE ergänzen. Da gibt es auch Auto-Completion. Den aufgezeichneten Test kann man als HTML-Test oder JUnit-Test oder, oder, oder exportieren.
Jetzt wird gezeigt, wie man eine Google-Maps-artige AJAX-Anwendung testet - Selenium kann alles testen, wo man draufclicken kann. Beeindruckend!
So gehen sie bei Thought-Works vor: Wenn eine Story implementiert ist, zeichnet der Business-Expert den Durchlauf durch die Anwendung auf und die Entwickler ergänzen fehlende Asserts.
In Kürze soll eine Integration mit FIT kommen.
Es wird gefragt, wie es mit der Wartbarkeit der Tests steht: Neal exportiert die Tests nach Java bzw. Ruby und bearbeitet sie dort weiter. Ohne diese "Aufarbeitung" sind die Tests sehr fragil.
Man kann HTML und JavaScript testen, aber kein Flash, ActiveX etc. iFrames gehen aber. Für HTTPS muss man das Zertifikat einmalig importieren.
Load-Testing geht (noch) nicht. "We kill only one Mercury product at a time."
(Der Referent benutzt nicht nur einen Mac, sondern auch IntelliJ - sonst sieht man ja immer nur Eclipse.)
Fazit
Selenium ist sehr mächtig. Das bezahlt man mit Komplexität. Die Tests, die man als Web-Seiten beschreibt wirken fast wie eine eigene Programmiersprache. Ich kann mir nicht vorstellen, dass Anwender solche Tests selber schreiben. Sie können sie aufzeichnen, aber anschließend nicht mehr warten / verstehen.
Für Tests, die die Entwickler schreiben, ist Selenium sicher interessant.
Selenium ist ein funktionales Open-Source Testtool für Webanwendungen, geschrieben in JavaScript.
Man schreibt die Tests ähnlich wie bei FIT-Action-Fixtures auf. Ausgeführt wird der Test im Browser. Dabei wird alles mögliche unterstützt, z.B. auch Popup-Fenster.
Im Test muss man natürlich die Elemente auf der HTML-Seite adressieren. Das geht über IDs und Namen und den DOM. Letzteres braucht man vor allem für Elemente, denen man keine IDs gibt, wie z.B. Ausgabetabellen.
Es gibt ein Firefox-Plugin namens XPather: Damit clickt man auf ein Element auf der Seite und bekommt den DOM-Pfad angezeigt, den man dann in den Test einpasten kann.
Bei der String-Prüfung werden auch Wildcards und Regexps unterstützt.
Das Adressieren der Elemente und die Prüfung der Seiteninhalte ist also sehr flexibel.
AJAX geht auch.
Es gibt ein paar Geschichten, die doch nicht gehen: z.B. wenn man in Java-Script als Reaktion auf onload einen Dialog öffnet. File-Upload funktioniert nur in Firefox.
Variablen werden unterstützt. So kann man einen Wert, den die Anwendung generiert, in einer Variablen starten und woanders wieder einfügen. Variablenwerte kann man auch durch JavaScript berechnen lassen.
Der Referent rät dazu, hart-codierte Werte in Akzeptanztests zu vermeiden. Ich habe aber nicht verstanden, wie er die umgeht.
Selenium lässt sich in automatic-builds integrieren. Dazu muss man anscheinend nur den Browser mit der URL des Tests aufrufen. Ich bin nicht ganz sicher, aber es scheint so, dass Selenium das Ergebnis dann an den Integration-Server POSTet.
Normalerweise muss man die Anwendung zum Testen serverseitig mit dem Browser-Bot starten. Mit Remote-Control-Selenium braucht man das nicht und kann so Seiten testen, die dafür nicht vorbereitet sind (z.B. Google). Das läuft über einen Proxy-Server. Damit kann man nicht nur die Tests ausführen, sondern auch über die Kommdozeile die Web-Anwendung fernzusteuern. Also kann man die Selenium-Tests auch als JUnit-Tests oder in Ruby oder sonstwas schreiben. Jetzt zeigt er einen Selenium-Test in JUnit. Das sieht eher unübersichtlich aus - die HTML-Version des Tests ist übersichtlicher. Vielleicht helfen beim JUnit-Test auch ein paar Extract-Methods.
"Web Developer Toolbar"-Plugin für Firefox und Internet-Explorer ist nützlich.
Es gibt eine Selenium-IDE als Firefox-Plugin. Damit kann man Tests aufzeichnen und wieder ausführen. In dem Test gibt es natürlich kaum Asserts. Die fehlenden Asserts kann man direkt in der IDE ergänzen. Da gibt es auch Auto-Completion. Den aufgezeichneten Test kann man als HTML-Test oder JUnit-Test oder, oder, oder exportieren.
Jetzt wird gezeigt, wie man eine Google-Maps-artige AJAX-Anwendung testet - Selenium kann alles testen, wo man draufclicken kann. Beeindruckend!
So gehen sie bei Thought-Works vor: Wenn eine Story implementiert ist, zeichnet der Business-Expert den Durchlauf durch die Anwendung auf und die Entwickler ergänzen fehlende Asserts.
In Kürze soll eine Integration mit FIT kommen.
Es wird gefragt, wie es mit der Wartbarkeit der Tests steht: Neal exportiert die Tests nach Java bzw. Ruby und bearbeitet sie dort weiter. Ohne diese "Aufarbeitung" sind die Tests sehr fragil.
Man kann HTML und JavaScript testen, aber kein Flash, ActiveX etc. iFrames gehen aber. Für HTTPS muss man das Zertifikat einmalig importieren.
Load-Testing geht (noch) nicht. "We kill only one Mercury product at a time."
(Der Referent benutzt nicht nur einen Mac, sondern auch IntelliJ - sonst sieht man ja immer nur Eclipse.)
Fazit
Selenium ist sehr mächtig. Das bezahlt man mit Komplexität. Die Tests, die man als Web-Seiten beschreibt wirken fast wie eine eigene Programmiersprache. Ich kann mir nicht vorstellen, dass Anwender solche Tests selber schreiben. Sie können sie aufzeichnen, aber anschließend nicht mehr warten / verstehen.
Für Tests, die die Entwickler schreiben, ist Selenium sicher interessant.
Angriffe auf Webanwendungen
Jetzt mache ich mal Werbung für die Konkurrenz: Unserem Stand gegenüber steht "Optima bit". Die machen mehrfach am Tag Live-Vorführungen, wie man Web-Anwendungen angreifen kann mit SQL-Injection und Cross-Site-Scripting. Die Vorführung ist kurz, knackig, leicht verständlich und etwas beunruhigend.
BOF. Die Zukunft der Programmiersprachen
Der Raum war ausgerichtet auf eine Art Panel-Diskussion - vorne Stühle für die Speaker und hinten Stühle für die Zuschauer. Markus Völter meinte, ein BOF sei anders. Mehr so, dass Speaker und Teilnehmer zusammen im Kreis sitzen und miteinander diskutieren.
Dazu waren aber definitiv zu viele Leute (100?) da. Also hat Markus vorne Zettel mit Thesen hingelegt. Wir sind dann einmal nach vorne gegangen, haben uns ein Thesenpapier genommen und das dann "vertreten". Natürlich waren die Zettel nur die Startpunkte für die Diskussion.
Die Diskussion selbst war lebhaft, aber dann doch auf wenige beschränkt. Manchmal driftete sie vom eigentlichen Thema ab, aber das haben die Speaker dann wieder eingefangen.
Zuerst ging es um das Thema AOP. Ca. die Hälfte der Anwesenden nutzt AOP. Die meisten aber nur dadurch, dass sie Spring einsetzen. Nur ein kleiner Teil benutzt AspectJ. Niemand benutzt AOP für was anderes als die üblichen rein technischen Beispiele Logging, Tracing, Transaktionshandling und Security. Die meisten finden AOP eine interessante Technologie, hatten aber im Ansatz eine Vorstellung davon, wie man funktionale Aspekte definieren soll. Ein Teil der Teilnehmer fand AOP in Gesamtgröße a la AspectJ auch viel zu kompliziert.
Bei der Komplexität fanden einige, dass Java zu kompliziert wird. Dierk König (sinngemäß): "Für mich hat JDK 1.4 gereicht. Java 5 ist für mich zu kompliziert." Es gab eine ziemliche Einigkeit darüber, dass die Zukunft der Programmiersprachen in Einfachheit liegen müsste. Dabei gingen die Meinungen auseinander, ob man ein einfacheres Java braucht, eher was Dynamisches a la Ruby oder Groovy oder gar etwas Funktionales a la Scala. Dabei gab es ein erstaunliches Interesse an funktionaler Programmierung. Das rekursive Programmieren sei vielleicht am Anfang gewöhnungsbedürftig, aber das sei OO auch. Außerdem bieten funktionale Programmierung den Vorteil, dass man das Programm transparent parallel ausführen kann. Das ist vor der Diskussion um Multi-Core-Prozessoren und ihre Auswirkungen auf die Programmierung natürlich ein echtes Argument - jedenfalls, wenn man glaubt, dass man in seinen Programmen die Multi-Core-Fähigkeit ausnutzen muss und nicht sowieso durch die Datenbank ausgebremst wird.
Dann gab es noch eine Diskussion um Closures. Alle wollen Closures. Dierk sagt, dass noch nicht raus ist, ob und wenn ja in welcher Form Closures in Java 7 enthalten werden. Er glaubt, dass man in Java über anonyme Inner-Classes letztlich nicht herauskommen wird.
Insgesamt war es eine interessante Session.
Dazu waren aber definitiv zu viele Leute (100?) da. Also hat Markus vorne Zettel mit Thesen hingelegt. Wir sind dann einmal nach vorne gegangen, haben uns ein Thesenpapier genommen und das dann "vertreten". Natürlich waren die Zettel nur die Startpunkte für die Diskussion.
Die Diskussion selbst war lebhaft, aber dann doch auf wenige beschränkt. Manchmal driftete sie vom eigentlichen Thema ab, aber das haben die Speaker dann wieder eingefangen.
Zuerst ging es um das Thema AOP. Ca. die Hälfte der Anwesenden nutzt AOP. Die meisten aber nur dadurch, dass sie Spring einsetzen. Nur ein kleiner Teil benutzt AspectJ. Niemand benutzt AOP für was anderes als die üblichen rein technischen Beispiele Logging, Tracing, Transaktionshandling und Security. Die meisten finden AOP eine interessante Technologie, hatten aber im Ansatz eine Vorstellung davon, wie man funktionale Aspekte definieren soll. Ein Teil der Teilnehmer fand AOP in Gesamtgröße a la AspectJ auch viel zu kompliziert.
Bei der Komplexität fanden einige, dass Java zu kompliziert wird. Dierk König (sinngemäß): "Für mich hat JDK 1.4 gereicht. Java 5 ist für mich zu kompliziert." Es gab eine ziemliche Einigkeit darüber, dass die Zukunft der Programmiersprachen in Einfachheit liegen müsste. Dabei gingen die Meinungen auseinander, ob man ein einfacheres Java braucht, eher was Dynamisches a la Ruby oder Groovy oder gar etwas Funktionales a la Scala. Dabei gab es ein erstaunliches Interesse an funktionaler Programmierung. Das rekursive Programmieren sei vielleicht am Anfang gewöhnungsbedürftig, aber das sei OO auch. Außerdem bieten funktionale Programmierung den Vorteil, dass man das Programm transparent parallel ausführen kann. Das ist vor der Diskussion um Multi-Core-Prozessoren und ihre Auswirkungen auf die Programmierung natürlich ein echtes Argument - jedenfalls, wenn man glaubt, dass man in seinen Programmen die Multi-Core-Fähigkeit ausnutzen muss und nicht sowieso durch die Datenbank ausgebremst wird.
Dann gab es noch eine Diskussion um Closures. Alle wollen Closures. Dierk sagt, dass noch nicht raus ist, ob und wenn ja in welcher Form Closures in Java 7 enthalten werden. Er glaubt, dass man in Java über anonyme Inner-Classes letztlich nicht herauskommen wird.
Insgesamt war es eine interessante Session.
XP-Live-Demo
it-agile hat in der XP-Live-Demo in einer Mischung aus Vortrag und "Theater" ca. 100 Teilnehmern vorgeführt, wie XP funktioniert. Matthias Lübken spielte den Kunden, Robert Beeger und Sebastian Sanitz die testinfizierten pair-programmierenden Entwickler. Stefan Roock moderierte.
XP-Live-Demo
it-agile hat in der XP-Live-Demo in einer Mischung aus Vortrag und "Theater" ca. 100 Teilnehmern vorgeführt, wie XP funktioniert. Matthias Lübken spielte den Kunden, Robert Beeger und Sebastian Sanitz die testinfizierten pair-programmierenden Entwickler. Stefan Roock moderierte.
Abonnieren
Posts (Atom)
