Die Abwicklung von Optionen bildet den Kern des modularen Ansatzes der Trade Federation. Insbesondere sind Optionen der Mechanismus, mit dem Entwickler, Integratoren und Testläufer zusammenarbeiten können, ohne sich gegenseitig die Arbeit zu duplizieren. Einfach ausgedrückt ermöglicht unsere Implementierung
des Optionsbehandlungs die
um ein Java-Klassenmitglied als konfigurierbar zu markieren, wobei der Wert dieses Mitglieds
kann vom Integrator erweitert oder überschrieben und anschließend durch
den Test-Runner. Dieser Mechanismus funktioniert für alle Java-internen Typen sowie für alle Map- oder Collection-Instanzen von internen Typen.
Hinweis: Der Mechanismus zur Optionenverwaltung funktioniert nur für Klassen, die eine der im Testlebenszyklus enthaltenen Schnittstellen implementieren, und nur dann, wenn diese Klasse vom Lebenszyklusmechanismus instanziert wird.
Entwickler
Zuerst kennzeichnet der Entwickler ein Mitglied mit der Anmerkung @Option.
Sie geben mindestens die Werte name und description an, die
den Namen des Arguments für diese Option und die Beschreibung, die auf
der TF-Konsole, wenn der Befehl mit --help oder --help-all ausgeführt wird.
Angenommen, wir möchten einen funktionalen Telefontest erstellen, der verschiedene Telefonnummern wählt und nach der Verbindung eine DTMF-Tonfolge von jeder Nummer erwartet.
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 sind alles, was der Entwickler braucht, um zwei Konfigurationspunkte dafür einzurichten.
testen. Er könnte dann mWaitTime und mCalls wie gewohnt verwenden,
ohne dabei die Konfiguration zu beachten. Da die @Option-Felder nach der Instanziierung der Klasse, aber vor dem Aufruf der run-Methode festgelegt werden, können Implementierer auf einfache Weise Standardwerte für Map- und Collection-Felder einrichten oder eine Art Filterung für diese Felder ausführen, die ansonsten nur zum Anhängen vorgesehen sind.
Hersteller
Der Integrator arbeitet mit Konfigurationen, die in XML geschrieben werden. Mit dem Konfigurationsformat kann der Integrator einen Wert für jedes @Option-Feld festlegen (oder anhängen). Beispiel:
Angenommen, der Integrator möchte einen Test mit geringerer Latenz definieren, der die Standardnummer sowie
als lang andauernden Test, bei dem
verschiedene Nummern angerufen werden. Er könnte zwei Konfigurationen erstellen, die so 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>
Test-Ausführer
Der Test Runner hat auch über die Trade Federation-Konsole Zugriff auf diese Konfigurationspunkte.
Zunächst führen sie einen Befehl (d. h. eine Konfiguration und alle ihre Argumente) mit dem Befehl
Anweisung run command <name> (oder kurz run <name>).
Darüber hinaus können sie eine beliebige Liste von Argumenten im Befehl angeben, die
Anfügen an Felder, die durch Lebenszyklusobjekte in den einzelnen Konfigurationen angegeben sind.
Um den Test mit niedriger Latenz mit den many-numbers Telefonnummern 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*#*#
Um einen ähnlichen Effekt aus der entgegengesetzten Richtung zu erzielen, könnte der Test-Runner die Wartezeit verkürzen.
Zeit für den many-numbers-Test:
tf> run many-numbers.xml --timeout 5000
Reihenfolge der Optionen
Die zugrunde liegende Implementierung der Option call ist ein Map
Nach wiederholten --call in der Befehlszeile werden sie alle gespeichert.
Die Option timeout, die eine zugrunde liegende Implementierung von long hat, kann nur einen Wert speichern. Es wird also nur der zuletzt angegebene Wert gespeichert.
--timeout 5 --timeout 10 ergibt timeout mit dem Wert 10.
Bei einer List- oder Collection-Implementierung werden alle Werte in der in der Befehlszeile angegebenen Reihenfolge gespeichert.
Boolesche Optionen
Optionen mit booleschen zugrunde liegenden Typen können auf true gesetzt werden, indem der Optionenname direkt übergeben wird, z. B. --[option-name]. Mit der Syntax --no-[option-name] können sie auf false gesetzt werden.