Test Guidelines
Die TSO Test Guidelines definieren, worauf bei der Entwicklung von automatisierten Softwaretests zu achten ist.
Test Toolkit
Das Standard Test Toolkit von Microsoft sollte Voraussetzung für jede Testentwicklung sein. Hier sind Basisfunktionalitäten für die Entwicklung enthalten.
Microsoft veröffentlicht zu jeder Produkt DVD, also zu jedem CU, ein eigenes Test Toolkit. Dieses ist in der Cronus Datenbanksicherung nicht enthalten und muss manuell importiert werden.
Test Toolkit im Client
Um Tests standardisiert auszuführen, sollten die Tests über das Test Tool im Business Central Client gestartet werden. Für die Ausführung des Tests muss die Spracheinstellung Englisch im Client ausgewählt sein. Beim Starten der Tests über den Client wird intern eine Codeunit vom Typ TestRunner ausgeführt. Das Codeunit Property TestIsolation gibt an, wann die durch den Test erzeugten Daten wieder abgeräumt werden. Bei Nutzung des Standard Test Runners werden die Daten nach der vollständigen Ausführung der Test-Codeunit gelöscht.
Test Toolkit in C/AL
Das Test Toolkit liegt in C/AL auf der Produkt DVD im Ordner TestToolKit und besteht aus folgenden drei fob Dateien.
- CALTestCodeunits.DE.fob
- Codeunits mit Testfunktionen
- CALTestLibraries.DE.fob
- Codeunits mit Funktionen zur Datenerzeugung
- CALTestRunner
- Codeunits zur standardisierten Ausführung
Test Toolkit in AL
Microsoft hat in AL die drei C/AL fobs in mehrere Test Apps ausgelagert. Auf der Produkt DVD sind die verschiedenen Microsoft Apps im Ordner Applications abgelegt. Dort gibt es neben dem Source Ordner, der den Quellcode der App enthält einen Test Ordner, der eine oder mehr Testapps enthält. Die Testapps sind dadurch nur über eine Abhängigkeit mit der Geschäftslogik verknüpft. Um die Geschäftslogik sauber von dem Testcode trennen zu können, ist dieses Vorgehen empfehlenswert.
Damit auch in AL Funktionalitäten des Standard Test Toolkits genutzt werden können, muss eine eigens entwickelte Testapp Abhängigkeiten auf die Testapps von Microsoft haben. In der Regel wird hier aber wohl lediglich eine Abhängigkeit auf die Microsoft_Tests-TestLibraries.app benötigt. Hier sind alle Library Codeunits enthalten, die für die Erzeugung von Daten benötigt werden .
Regeln für Testfunktionen
Die TSO Entwicklungsmethodik und die allgemeingültigen Clean Code Regeln gelten auch für Test Code. Zusätzlich sind folgende Punkte für Testfunktionen zu beachten.
Keine vorhandenen Daten voraussetzen
Testfunktionen dürfen keine Abhängigkeiten auf die Entwicklungsdatenbank haben. Es dürfen also in den Testfunktionen keine bestehenden Daten aus der Datenbank genutzt werden. Auch für den Testfall benötigte Einrichtungsdaten müssen gesetzt werden.
Hintergrund ist, dass man die Tests wiederholt und ggf. auch in einem nächtlichen Buildprozess durchführen möchte. In den Buildprozessen würden die Tests in einer leeren Cronus Datenbank ausgeführt werden.
Best practice: Testentwicklung in einer Datenbank, die nur Cronus Daten enthält.
Testdaten erzeugen
Microsoft kapselt die Erzeugung von Testdaten in Library Codeunits. Diese Codeunits enthalten Funktionen, die einen Datensatz mit Standardwerten erzeugen.
Für Individualtabellen sind eigene Library Codeunits zu erstellen.
Bei der Erzeugung von Testdaten ist darauf zu achten, dass Felder nicht hart codiert werden. Besser ist es mit Zufallsdaten zu arbeiten. Die Codeunits Library – Random und Library – Utility enthalten Funktionen, die abhängig von Datentypen Zufallsdaten zurückgeben.
Testfälle isolieren
Eine Testfunktion soll einen Testfall abdecken.
Damit ist gemeint, dass man nicht verschiedene Funktionalitäten in einem Testfall prüft. Dadurch soll verhindert werden, dass Testfälle voneinander abhängen.
Man möchte nicht, dass durch einen gescheiterten Testfall weitere Tests fehlschlagen. Deshalb sollten Testfunktionen sich auch nicht auf Daten aus anderen Testfunktionen beziehen.
Beispiel:
Wenn man den Buchungsprozess testen möchte, würde man nicht einen Auftrag erzeugen, freigeben und danach buchen. Dies hätte nämlich zur Folge, dass ein Problem beim Freigeben den Buchungstest fehlschlagen ließe.
Richtig wäre, direkt einen freigegebenen Auftrag zu erzeugen und nur die Buchungsfunktion aufzurufen. Die Freigabe eines Auftrags wäre ein eigener Test.
Prüfung der Testergebnisse
Für die Prüfung der Testfälle stellt Microsoft die Assert Codeunit bereit. Durch die Nutzung wird sichergestellt, dass im Fehlerfall standardisierte Fehlermeldungen ausgegeben werden. Diese Fehlermeldungen können durch den Message Parameter noch konkretisiert werden.
Handler Functions
Um Prozesse mit Benutzerinteraktion zu testen, werden Handlerfunctions benötigt. Sie geben einerseits an, dass die aufgetretene Interaktion zum Prozess dazugehört und steuern andererseits, wie der User auf die Interaktion reagieren würde. Also z.B. ob der User für meinen Testfall ein Confirm bestätigen oder ablehnen sollte. Pro Benutzerinteraktion (Message, Confirm, Page, ModalPage usw.) ist eine eigene Handlerfunction zu definieren und dem Testfall zuzuordnen.