Das Optionshandling ist das Herzstück des modularen Ansatzes der Trade Federation. Optionen sind insbesondere der Mechanismus, mit dem Entwickler, Integrator und Testläufer zusammenarbeiten können, ohne die Arbeit des anderen duplizieren zu müssen. Vereinfacht gesagt ermöglicht unsere Implementierung der Optionsbehandlung dem Entwickler, ein Java-Klassenmitglied als konfigurierbar zu markieren. Zu diesem Zeitpunkt kann der Wert dieses Mitglieds vom Integrator erweitert oder überschrieben werden und anschließend vom Test Runner erweitert oder überschrieben werden. Dieser Mechanismus funktioniert für alle intrinsischen Java-Typen sowie für alle Map
oder Collection
von intrinsischen Typen.
Hinweis: Der Mechanismus zur Optionsbehandlung funktioniert nur für Klassen, die eine der im Testlebenszyklus enthaltenen Schnittstellen implementieren, und nur, wenn diese Klasse von der Lebenszyklusmaschinerie instanziiert wird.
Entwickler
Zu Beginn markiert der Entwickler ein Mitglied mit der Annotation @Option
. Sie geben (mindestens) die name
und description
an, die den mit dieser Option verknüpften Argumentnamen angeben, sowie die Beschreibung, die auf der TF-Konsole angezeigt wird, wenn der Befehl mit --help
oder --help-all
ausgeführt wird.
Nehmen wir als Beispiel an, wir möchten einen funktionalen Telefontest erstellen, der eine Vielzahl von Telefonnummern wählt und erwartet, von jeder Nummer eine Folge von DTMF-Tönen zu empfangen, nachdem eine Verbindung hergestellt wurde.
public class PhoneCallFuncTest extends IRemoteTest { @Option(name = "timeout", description = "How long to wait for connection, in millis") private long mWaitTime = 30 * 1000; // 30 seconds @Option(name = "call", description = "Key: Phone number to attempt. " + "Value: DTMF to expect. May be repeated.") private Map<String, String> mCalls = new HashMap<String, String>; public PhoneCallFuncTest() { mCalls.add("123-456-7890", "01134"); // default }
Das ist alles, was der Entwickler benötigt, um zwei Konfigurationspunkte für diesen Test einzurichten. Sie könnten dann loslegen und mWaitTime
und mCalls
wie gewohnt verwenden, ohne groß auf die Tatsache zu achten, dass sie konfigurierbar sind. Da die @Option
Felder nach der Instanziierung der Klasse, aber vor dem run
der Ausführungsmethode festgelegt werden, bietet dies für Implementierer eine einfache Möglichkeit, Standardwerte für Map
und Collection
einzurichten oder eine Art Filterung durchzuführen, die ansonsten angehängt werden. nur.
Integrator
Der Integrator arbeitet in der Welt der Konfigurationen, die in XML geschrieben sind. Das Konfigurationsformat ermöglicht es dem Integrator, einen Wert für jedes @Option
Feld festzulegen (oder anzuhängen). Angenommen, der Integrator möchte einen Test mit geringerer Latenz definieren, der die Standardnummer anruft, sowie einen Langzeittest, der verschiedene Nummern anruft. Sie könnten ein Paar Konfigurationen erstellen, die wie folgt aussehen könnten:
<?xml version="1.0" encoding="utf-8"?> <configuration description="low-latency default test; low-latency.xml"> <test class="com.example.PhoneCallFuncTest"> <option name="timeout" value="5000" /> </test> </configuration>
<?xml version="1.0" encoding="utf-8"?> <configuration description="call a bunch of numbers; many-numbers.xml"> <test class="com.example.PhoneCallFuncTest"> <option name="call" key="111-111-1111" value="#*#*TEST1*#*#" /> <option name="call" key="222-222-2222" value="#*#*TEST2*#*#" /> <!-- ... --> </test> </configuration>
Testläufer
Der Test Runner hat auch über die Trade Federation-Konsole Zugriff auf diese Konfigurationspunkte. In erster Linie führen sie einen Befehl (d. h. eine Konfiguration und alle ihre Argumente) mit der Anweisung run command <name>
(oder kurz run <name>
) aus. Darüber hinaus können sie eine beliebige Liste von Argumenten angeben, die Teil des Befehls sind und die von Lifecycle Objects in jeder Konfiguration angegebenen Felder ersetzen oder an diese anhängen können.
Um den Test mit geringer Latenz mit den Telefonnummern many-numbers
auszuführen, könnte der Test Runner Folgendes ausführen:
tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#
Oder um einen ähnlichen Effekt aus der entgegengesetzten Richtung zu erzielen, könnte der Test Runner die Wartezeit für den Test many-numbers
verkürzen:
tf> run many-numbers.xml --timeout 5000
Optionsbestellung
Möglicherweise stellen Sie fest, dass die der Implementierung zugrunde liegende call
eine Map
ist, sodass bei wiederholtem --call
in der Befehlszeile alle gespeichert werden.
Die Option timeout
, der eine Implementierung von long
zugrunde liegt, kann nur einen Wert speichern. Es wird also nur der zuletzt angegebene Wert gespeichert. --timeout 5 --timeout 10
führt zu timeout
mit 10.
Im Falle einer List
oder Collection
als zugrunde liegende Implementierung werden alle Werte in der in der Befehlszeile angegebenen Reihenfolge gespeichert.
Boolesche Optionen
Optionen des zugrunde liegenden booleschen Typs können durch direkte Übergabe des Optionsnamens, z. B. --[option-name]
auf „ true
“ gesetzt werden und können mit der Syntax --no-[option-name]
auf „ false
gesetzt werden.