8:40 Erster Workshop, Pleiten, Pech und Pattern Testing
Erstes Beispiel für fehlgeschlagenes Testing: Ariane 4 Übergang auf Ariane 5. Oh yes, I remember it well.
Die grösste Panne ist die Gestaltung der Folien, viele Teile des Textes sind wegen unvorteilhafter Farbgebung kaum lesbar.
Security Chip auf vielen EC Karten fehlerhaft. Warum war der Chip so schnell abschaltbar?
Pattern stellen guten Code dar, Code, wie er gewünscht ist
AntiPattern für Worst Case Coding. (Spagetti Code, Dead Code)
Auch als Bibliothek einbindbar für nicht aspectj affine Häuser.
Mit Maven ist es direkt einbindbar als org.patterntesting…….Für offline Testing bietet sich die Annotation „Integrationstest“ an. Alle Tests, die laut Property Testing nicht auf IntegrationTest stehen, werden ausgelassen.
Weitere Annotationen sind @SmokeTest, @Broken, @RunTestOn(„MacOSX“)
@SkipTest(„Linux“) @Deprecated, @TestException
Bei Socket oder Http Errors ist immer interessant, welcher Server angesprochen wurde.
Hier bietet sich PatternTesting Exception zur informativen Anreicherung an.
Stichwort für die Suche nach Bad Practices Pattern Testing (eigentlich AntiPatternTesting)
Die Vortragenden wechseln showhaft zu einem Problemfall. Gute Idee, die Zuschauer sind aufgewacht.
Stichwort Junit Test, eine Sache die schon die wenigsten Projekte nutzen.
Besides, die Demo läuft natürlich mit Eclipse.
Pattern Testing benötigt das AspectJ Plugin, da Pattern Testing Teil von AspectJ
Vortrag wird hauptsächlich über Code Demo dargestellt.
Pointcuts mit Wildcards können dezidiert Punkte im Programm ansprechen mit spezifischen Features. Hier können dan Check Anforderungen „eingewoben“ werden.
Über den Runtime Monitor können Systemparameter überwacht werden wie Classpath Doubletten o.ä.
http://patterntesting.org für mehr Infos bzw. http://oli.blogger.de
8:45 Java GUI Testing von A-Z
Vortrag der Firma Froglogic
Gui Testen, Bedienung der grafischen Oberfläche wie ein Anwender und Abprüfung erwarteter Resultate-> Funktionales GUI Testen
Kann mit Coverage Tests und Load/Stress Tests kombiniert werden
Es werden stehts Anforderungen bzw. Use Cases als Basis benötigt.
Mit der am häufigsten genutzten Funktionalität beginnen (Priorisierung auf das wichtige)
Manuelle Tests sind fehleranfällig, langweilig und dauern recht lange. Menschliche Tester sind zudem „teuer“.
Problem auch, es wird nicht immer genau gleich getestet, der Testablauf als solcher kann sich ändern.
Automatische Tests haben eine hohe initiale Hürde, aber sie sind schneller, skalierbarer, lassen sich einfacher in unterschiedlichen Konfigurationen nutzen und günstiger „in the long run“.
Meist existiert ein gemischtes Vorgehen aus manuellen Tests zu Beginn und immer mehr automatischen Tests zum Ende hin. Aber es wird auch immer manuelle Tests geben.
Am Beginn steht die Auswahl des Werkzeugs:
Hat es Support für mein Toolkit
Kann ich auf den Non-GUI Layer zugreifen
Wird scripting unterstützt?
Wird meine Plattform unterstützt?
Ist es erweiterbar?
Wie stehts es um den Support?
Bekomme ich Hilfe, wenn nötig?
Update Strategie?
GUI Tests sind nix für „nebenher“. Die Testfälle müssen nicht nur eingerichtet sondern auch gepflegt werden. Die Rolle für eine spezielle Person.
Beginnen mit den „low hanging fruits“
Automatisierte Ausführung der Testfälle sollte frühzeitig angedacht und implementiert werden. Test müssen z.B. via cron Jobs ohne Eingriff automatisch zu bestimmten Zeitpunkten oder unter bestimmten Bedingungen durchgeführt werden.
Ergebnisse sollten für alle verfügbar sein. Hudson oder Cruise Control sollten auch ausgewählte GUI Tests mit ansprechen.
Test Management Tool für die Verwaltung der Ergebnisse einsetzen.
Auch die Fehlerbereinigung muss koordiniert werden. Abnahme nur ohne unerwartete Fehler.
11:15 Bessere Tests mit JUnit 4.X
David Saff:JUnit is the intersection of all possible useful java test frameworks, not their union.
Kent Back: A programmer-oriented Testing Framework
Ab 4.x neue Features:
assertThat(1 + 1, is(2));
Matcher lassen sich einfacher kombinieren.
Vordefinierte Matcher (is, not, allOf, anyOf, nullValue,…..
weitere Matcher über hamcrest, auch die Möglichkeit, eigene Matcher zu definieren.
Mittels hamcrest lassen sich auch Matcher Bibliotheken erstellen.
Parametrisierte Tests seit 4.x möglich auch mit Methoden, dazu gibt es die sogenannten Theories
Rules als Erweiterungsmechanismus für Tests um z.B. beim Test eigenen Code einzufügen.
Und Rules können auch selbst entwickelt werden.
Categories ermöglichen Trennung von Tests, so daß nicht alle Tests immer ausgeführt werden.
Kategorie ist Klasse oder Interface, annotiert mit Category @Category(Slow.class)
Migration auf neue JUnit Version ist denkbar einfach, alle alten Tests laufen immer noch.
12:15 OSGi Lessons learned: Best and Worst Practices
Best practices: Don’t program OSGi (nicht gegen die APIs programmieren)
Idee dahinter: pojo basiert bauen, die Umgebung „ignorieren“ und sich dadurch nicht davon abhängig machen.
„Your code sucks. Versioning can help!“
Klare Gedanken über Modulgrenzen machen „Good fences make good neighbours“. Was muss zwischen Bundles sichtbar sein, was nicht.
Es gibt keine allgemeingültige Grössendimensionen für Bundles. Aber nicht zu gross werden lassen.
Auf die Abhängigkeiten zwischen den Modulen achten, daraus ergibt sich, wie gut das System weiterentwickelt werden kann. Modular heisst auch, wenige Abhängigkeiten.
OSGi Services verwenden, das ist die Grundlage der ganzen Idee.
Gut überlegen, wo es sich lohnt, einen OSGi Service draus zu machen.
Hmm, also einige der Aussagen sind aber nun wirklich nicht OSGi spezifisch, sondern eigentlich was jeder gute Entwickler sich auf die Fahnen schreiben sollte, egal mit was er arbeitet.
Man soll in OSGi testen.. Ersetze OSGi durch IMMER!
Nach der Mittagspause:
14:30 Java Entwicklung für Embedded Devices
-Famous Last Words-
„Ja, kein Problem, ich schaff das“
Oft sehen Entwickler nicht die Unterschiede zwischen Java Midlet und Standard Edition!
Ggf. müssen Libraries portiert werden.
Der Compiler Level ist NICHT das Hauptproblem. Am besten auf spezielles Environment für Mobile Entwicklung wechseln.
Tests müssen am Device erfolgen. Und damit ist nicht die Emulation gemeint.
Immer dran denken. Es gibt Speicherlimits auf Mobile Devices.
Merke: Lessons Learned und Famous Last Words Vorträge in Zukunft meiden, das meiste ist offensichtlich und wird nur von jenen nicht gelernt, die sich nicht für die Sache an sich interessieren.
Best Practices, oder wie ich zu sagen pflege. Gesunder Menschenverstand!
Lol, da wurde ja hauptsächlich über die Entwicklung für Windows Mobile berichtet. Also garnicht über vernünftige Embedded Devices….
Interessant, wie oft die guten Ideen der neuen Technologien ignoriert werden. Die IPhone GUI ist kein Hype, Windows Mobile ist tot. Veraltet, Computersteinzeit und klassisches Java Mobile ist bald irrelevant.
Ich mache mir langsam Sorgen um die Sichtweisen einiger Java Protagonisten. Die verlieren nach den Sprüchen, die hier so abgesondert werden, so langsam den Anschluss an die Zukunft.
15:30 Android- Java für unterwegs.
Die Jungs sind schon mal sehr amüsant. Wer ihnen folgen möchte: @elektrojunge @derwildemomo
Es wird aber mehr eine Vorstellung, was eigentlich Android ist. Insofern wenig Live Bloggbarer Inhalt, werd es einfach still geniessen und ggf. ein paar Facts einwerfen.
Zur Historie: 2008 wurde die Plattform angekündigt.
Guter Vortrag der Vor- und Nachteile darstellt. Google als offenes System mit allen Vor- und Nachteilen. Remote Wipe wird erwähnt, ebenso wie die anderen Remote Möglichkeiten und die Fähigkeit, auch auf die Hardware zuzugreifen.
Mit Froyo geht auch im Browser ein Zugriff auf die Hardware.
Fazit ist Froyo macht Android auch fürs Unternehmen interessant, aber Business Integration ist nicht so einfach, wie manche sich das vorstellen. Jetzt für die Techniker unter uns die Dalvik VM.
Dalvik ist der Kern des ganzen, durch die Dalvik Engine ist Android performant. ABER, es gibt keine Verwendbarkeit des klassischen Java Bytecodes.
Für mich ist der Vortragsblock damit durch, jetzt noch Social Networking und Business Card Sharing.
Alles in allem wieder eine gelungene Veranstaltung, vor allem auch dank interessanter Gespräche zwischen den spannenden Vorträgen und einigen neuen Kontakten, sei es in RL oder auch via Twitter. Der Tag hat mich wieder inspiriert und Lust auf neue Entwicklertätigkeiten auch im Android Umfeld gemacht. Ein paar gute Ideen wachsen gerade, mal sehen, was daraus wird. Um es mal plakativ zu formulieren: „We ain’t seen nothing yet.“
