Skip to content

Latest commit

 

History

History
178 lines (128 loc) · 6.95 KB

ArchitekturEntscheidungen.adoc

File metadata and controls

178 lines (128 loc) · 6.95 KB
Raw

Architekturentscheidungen

Technische Aspekte der fachlichen Umsetzung

  • Der Jenkins wird über einen REST Client abgefragt

  • Die Statusabfragen werden per Polling in einem konfiguriertem Zeitintervall gesendet

  • Die optische Darstellung erfolgt im Window Tray

Entscheidung Programmiersprache

  • Das Programm soll auf möglichst vielen Plattformen laufen → fachliche Anforderung ist der Support von Windows 17.09.2019: Es wird Java SE verwendet.

Entscheidung Jenkins REST API

  • Aktuell sind bestimmte URL Pattern bekannt mit denen der Build Status vom Jenkins abgefragt werden kann

    Fachliche Anforderung ist eine Abfrage ohne Authentication
    17.09.2019:
Es werden folgende URL Pattern unterstützt:
** http://jenkinshost/job/freejobname/lastBuild/api/json
** http://jenkinshost/job/multibranchpiplinejobname/job/branchname/lastBuild/api/json

  • Es wird ein JSON Response erwartet welcher den Buildstatus des abgefragten Jobs beschreibt

    Fachliche Anforderung ist die Anzeige des Buildjob Namen und einen Status grün, gelb oder rot
    17.09.2019:
Aus dem Response JSON Objekt werden folgende Attribute ausgewertet:
** fullDisplayName
** result

Enscheidung GUI Technologie

  • Die Darstellung soll im Systemtray als Icon erscheinen

    Fachliche Anforderung ist:
** Bei Rechtsklick auf das Icon erscheint eine List der Buildjobsname in der Farbe des letzten Buildstatus
** Bei Linksklick auf das Icon erscheint ein Menü mit folgenden Einträgen:
   *** Reload Config -> liest die Konfigurationsdatei neu ein
   *** About -> Link zur Projektwebseite
    17.09.2019:
Java bietet mit AWT eine Möglichkeit GUI Elemente in den Systemtray zu bringen
Daher erfolgt die Implementierung über AWT Klassen.
Swing oder JavaFX werden nicht benutzt, um die Abhängigkeiten zu verringern

Entscheidung Entwicklungsmethode

  • Das Produkt soll professionelle Qualtiät über einen CI und Test first Ansatz sicherstellen

    Vorteile des test first Ansatzes:
** Eignet sich für Button Up. Daher kann mit der Entwicklung der eigentlichen Fachlichkeit sofort begonnen
   werden und später die Integration der Komponenten erfolgen
** Bei neuen Testtools kann mit einfachen Testfällen zunächst auch das Testwerkzeug erkundet werden.
    17.09.2019:
Die Sourcen werden auf github gehostet.
Die CI wird über Travis-CI realisiert.
Das Deployment erfolgt manuell über Bintray bis ins maven central.

Entscheidung Implementierung

  • Jenkins Abfrage

    17.09.2019:
Die Abfrage erfolgt per REST Client nach diesem Vorbild:
https://serverfault.com/questions/309848/how-do-i-check-the-build-status-of-a-jenkins-build-from-the-command-line

  • REST Client

    17.09.2019:
Client wird nach diesem Vorlbild implementiert:
https://alvinalexander.com/java/java-apache-httpclient-restful-client-examples

  • TrayIcon

    Fachliche Anforderung möglichst native, möglichst wenig Framework
    17.09.2019:
Implementierung erfolgt über awt Klassen nach diesem Vorbild:
https://ourcodeworld.com/articles/read/837/how-to-create-and-display-a-windows-10-notification-with-java-awt

Entscheidung Testvorgehen

Generell soll möglichst ohne Mock Frameworks ausgekommen werden. Hier sollte der test first Ansatz helfen weite Teile der Anwendung möglichst einfach mit eigenen Mocks oder Stubs testen zu können.

17.09.2019: Zur Testausführung wird vorwiegend das Framework JUnit5 genutzt.

  • Der REST Client

    Hier ist ein Framework notwendig, da sonst unverhältnismäßig viel Aufwand bei der Implementierung
der Mocks erwartet wird.
    17.09.2019:
Es wird zunächst versucht das Framework wireMock zu nutzen. Es soll mit geringen
Aufwänden im Maven Build nutzbar sein und die Testfälle lassen sich angeblich
recht einfach in JUnit per Rule beschreiben.
https://github.com/swtestacademy/junit5-wiremock-example
http://wiremock.org/
https://blog.jonas-hellmann.de/testen-eines-rest-clients-in-java-mit-wiremock/

  • Der Timer fürs Polling

    Hierfür dürfte bei entsprechender Programmierung kein Framework notwendig sein.
    17.09.2019:
Realisierung wie im Artikel beschrieben:
https://capgemini.github.io/development/testing-timers/

  • Die GUI Darstellung und Verhalten

    Hier wird ein Framework benötigt, da es unverhältnismäßig viel Aufwand bedeutet auf
OS Ebene zu testen.
    Das einzige mir aktuell bekannte Framewok ist FEST. Es liegen keine Erfahrungen vor.
    17.09.2019:
FEST wird zum Test der GUI Komponenten verwendet:
https://www.javaworld.com/article/2077740/test-driven-gui-development-with-fest.html
http://web.archive.org/web/20110101141359/http://fest.easytesting.org/
Alternativen:
https://testing.bredex.de/
https://sourceforge.net/projects/abbot/
http://abbot.sourceforge.net/doc/overview.shtml
http://www.cafeaulait.org/slides/sd2006west/guitesting/Testing_GUIs_with_Abbot_and_Costello.html

Lessons learned

Gray Anomalie Wenn man von BufferedImage createGraphics aufruft und ein Rechteck mit Color.gray füllt. Kann man im Test nicht vergleichen über assertEquals(Color.gray.getRGB(), image.getRGB(x,y) ) Es gibt eine leichte Wertdifferenz obwohl x und y im gefüllten Rechteck liegen. Bei Color.red gibt es keine Anomalie.

Literatur und Quellen im Netz