Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 2 Aktuelle »

Erste Analyse auf Basis von Linda

Grundlegendes

  • Tests werden in einer neuen Systementität gespeichert, und werden damit Teil des Nuclets.
    Linda: Komplette Eigenteile sind nicht testbar. ControllingFacade?! 

  • Testformat könnte ein Groovy Script sein, welches ausschließlich per Rest mit Nuclos kommuniziert. Damit ist gewährleistet, dass diese Tests auch mit zukünftigen Versionen von Nuclos laufen.

  • In der ersten Version wird nur die Businesslogik / Regeln im Server getestet.
    Linda: Nachteil: Die heutige Java Client Extension würde nicht getestet werden! 

  • Heutige Nuclos Webclient Test basieren ebenfalls schon auf Groovy und zukünftige GUI Tests (NAGT) könnten auch mal den Webclient direkt bedienen.
    Linda: Eine zukünftige Linda-Web-Version könnte getestet werden. 

  • Tests basieren immer auf einer leeren DB. Über eine Systemfunktion können sämtlich Inhalte aller BO Tabellen geleert werden.

  • Tests können auf einander aufbauen, ähnlich den Regeln. Wiederverwendbarkeit ist damit gegeben.

Aufzeichnung von Events

  • Variante 1 (Server - komplexer)
    Im Kern des Server, in den Facades selbst. Z.B. EntityObjectFacade, StatemodelFacade, GeneratorFacade…
    Welcher Client dabei verwendet wird ist nicht relevant.
    Vorteil: Java Client kann verwendet werden
  • Variante 2 (Webclient - einfacher)
    Der Webclient zeichnet „einfach“ seine Restcalls auf.
    Nachteil: Zur Aufzeichnung müssen alle Teile von Linda zumindest rudimentär über den Webclient bedienbar sein. Stichwort MatchBO

  • Events

    • Insert, update, delete
    • State change, object generation
    • Search, open details

Bearbeitung der Tests

  • Egal wie die Aufzeichnung stattfindet, die aufgezeichneten Events sind nur über den Webclient abrufbar und auch die Tests werden nur im Webclient bearbeitet und administriert.
  • Aus den Events wählt man sich die Einträge aus, die für den Test relevant sind. Diese werden dann in ein Groovyscript eingefügt und können dort weiter bearbeitet werden.
  • Ergebnisprüfung / Validierung

    • Inhaltsvergleich von Attributen und SubBos

    • Definierte Suchen und Anzahl gefundene Datensätze
    • Auftreten einer Exception

Ausführung

  • Starten einzelner oder aller Tests nur über den Webclient.

Testscript Beispiel (Umsetzbarkeit ist zu prüfen!)

def mllx1000 = new Leitung(identifizierer:'MLLX/nn/2001000', ...)
mllx1000.save()
mllx1000.lieferantenProdukt = 'DSL 16000'
mllx1000.save()
assert mllx1000.monatlicheKosten == 33.00
mllx1000.bearbeiter = 'Mustermann, Max'
mllx1000.changeState(50)
mllx1000.bearbeiter = null
mllx1000.save()
assert mllx1000.error == 'Bearbeiter muss ab Status immer gefüllt sein'
mllx1000.rollback()


Ausbaustufen

  • Eine GUI a la Automator wäre für simple Testscripte, wie im Beispiel, zumindest denkbar.



  • Keine Stichwörter