Ein Gastartikel von Sebastian Weha.
Sie kennen sicher den Software Development Lifecycle (SDLC). Er beschreibt die Stationen von der Anforderungsanalyse bis zur fertigen Software und deren Evaluierung. Um den SDLC umzusetzen, gibt es viele Methoden (und viele Diskussionen darum, welche davon die beste ist): Agile Softwareentwicklung, das Wasserfallprinzip, DevOps, ….
Eines haben alle diese Methoden gemeinsam: Auf das Testen der Software wird großer Wert gelegt.
Das gilt natürlich auch für die Automic Entwicklung – zumindest in der Theorie. In der Praxis wird das Testen hier aber eher stiefmütterlich behandelt.
Diese Erfahrung habe ich bei vielen Projekten gemacht. Deshalb kam mir die Idee, das Testen zu automatisieren und in best4Automic (b4A) eine Lösung dafür bereitzustellen.
Die Lösung basiert auf b4A Packages, die sich an die Struktur der Automic Action Packs anlehnen. In der Standard-Konfiguration wird die Struktur der Action Packs berücksichtigt, wer also bereits Action Packs nutzt, kann sofort durchstarten.
In Testspezifikationen legen Sie fest, welche Tests durchgeführt werden.
Wie sieht so eine Testspezifikation aus?
Die Tests werden in Cucumber bzw. mit der Gherkin Syntax beschrieben.
Grundsätzlich sind die Tests folgendermaßen aufgebaut:
- Feature: Beschreibt ein Set an Testfällen (Szenarios), die thematisch zusammenhängen.
- Scenario: Beschreibt einen einzelnen Testfall.
- Given: Beschreibt die Schritte, die vor der eigentlichen Testausführung überprüft werden (Vorbedingungen).
- When: Beschreibt die eigentliche Testausführung.
- Then: Beschreibt die Schritte, die nach der Testausführung überprüft werden (Nachbedingungen).
Um Ihnen dies an einem Beispiel zu erläutern, habe ich einen simplen Workflow angelegt. Dieser besteht aus einem PromptSet zur Texteingabe und einem Skript, das die Eingabe wieder ausgibt.
Diesen Workflow testen wir mit der folgenden Testspezifikation.
@PCK.PCK.PHILIPPELMER_TEST Feature: Teste das Paket für den Philipp Elmer Blogeintrag! @PRINT_OUT @TEST0001 Scenario: Test Skript und überprüfe ob die Eingabe im Report ausgegeben wird. Given Object PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT exists And Object PCK.PHILIPPELMER_TEST.SCRI.PRINTOUT exists And Object PCK.PHILIPPELMER_TEST.PRPT.PRINTOUT exists When Execute PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT |Key |Value | |INPUT# |Testeingabe | Then Task status of PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT is |Task |status | |PCK.PHILIPPELMER_TEST.SCRI.PRINTOUT(1) |ENDED_OK | And Check report ACT of PCK.PHILIPPELMER_TEST.SCRI.PRINTOUT from PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT for ".*Testeingabe.*"
Die Spezifikation enthält ein Feature mit einem sehr einfachen Szenario.
Zuerst prüfen wir im GIVEN, ob alle drei Objekte im Mandanten vorhanden sind. Ist eins nicht vorhanden, bricht der Test ab.
Der WHEN-Abschnitt beschreibt die Ausführung des Workflows und übergibt die PromptSet-Parameter. In der Tabelle stehen die PromptSet-Parameter, die übergeben werden (Key: INPUT#, Value: Testeingabe).
Das THEN überprüft, ob der Task im Workflow den Status ENDED_OK hat und ob der Report den eingegebenen Text enthält.
Natürlich könnten wir auch noch weitere Szenarien testen, zum Beispiel andere Eingaben. Für unser Beispiel ist das aber nicht nötig.
Wie wird eine Testspezifikation ausgeführt?
Die Gherkin-Syntax führt Tests über das Cucumber-Framework aus und ruft von dort die Ergebnisse ab. Dieser Schritt ist nicht ganz trivial, da wir einen Interpreter benötigen, der Automic in die erwarteten Ergebnisse und in eine für Cucumber verständliche Sprache übersetzt.
Wir haben das als Modul ta.Execute in der best4Automic Solution umgesetzt.
best4Automic
Für administrative Aufgaben oder im Rahmen von Projekten sind immer wieder umfangreiche manuelle Tätigkeiten auf der ONE Automation Platform notwendig: Massenänderungen, Aufräumaufgaben, aufwändige Analysen oder Daily Doing. Die best4Atomic Solution (b4A) bietet dafür ein umfangreiches Set von Modulen, die die Funktionalität Ihrer ONE Automation Plattform erweitern, die Arbeit vereinfacht und manuelle Fehler (insbesondere bei Massenänderungen) ausschließt.
Mit dem Modul können Sie die in Gherkin spezifizierten Testfälle ausführen. Sie können die Testspezifikation entweder als Textdatei übergeben oder in einem DOCU-Objekt hinterlegen. In diesem Fall habe ich das DOCU-Objekt angegeben. Das Modul speichert außerdem die Testergebnisse des letzten Runs (Objekt für Bericht).
Nach der Ausführung der Tests bekommen Sie einen Report mit den Ergebnissen.
Diesen Report finden Sie auch in dem Objekt, das Sie für den Bericht angegeben haben. Dadurch können Sie die Testergebnisse mit Automic-Skriptmitteln analysieren und weiterverarbeiten. Beispielsweise können Sie die Testergebnisse als E-Mail weiterleiten oder in eine Testmanagementsoftware übertragen.
Das Beispiel hier ist natürlich sehr vereinfacht. Normalerweise müssen Sie deutlich mehr Szenarien testen. Sie alle funktionieren aber nach dem gleichen Muster, das ich hier beschrieben habe.
Haben Sie schon eigene Ideen zum Testen Ihrer Automic-Workflows? Dann machen Sie sich doch gleich an die Umsetzung.
Sebastian Weha
Automic Experte und b4A-Entwickler
Sebastian ist zertifizierter Automic Experte und b4A-Entwickler. Mit großer Leidenschaft verzahnt er Automic mit anderen Produkten, steuert diese mittels Automic und vereinfacht und automatisiert so Arbeitsabläufe. Freizeit verbringt er mit seiner Familie und damit, neue Orte in der Welt zu bereisen.
best-blu – Consulting with Energy
best-blu ist auf Automation von Geschäftsprozessen großer und mittelständischer Unternehmen spezialisiert. Mit ca. 35 Mitarbeitern sind sie in den vier Kernbereichen der Digitalisierung tätig: Business Process Automation, Business Process Management, Softwareentwicklung und ERP-Prozesse (SAP). Als Premium Service Partner von Automic, mit derExzellenz-Initiative bestXperts und natürlich durch erfolgreiche Automations-Projekte bei namhaften Unternehmen, haben sie sich als Spezialist für Automation und Digitalisierung von Geschäftsprozessen einen Namen gemacht.