Der modulare Ansatz der Trade Federation basiert auf dem Umgang mit Optionen. Insbesondere sind Optionen
sind der Mechanismus, durch den Developer, Integrator und Test Runner zusammenarbeiten können, ohne
die Arbeit der anderen duplizieren müssen. Einfach ausgedrückt ermöglicht unsere Implementierung
des Optionsbehandlungs die
Ein Entwickler markiert ein Java-Klassenmitglied als konfigurierbar. Dann wird der Wert dieses Mitglieds
kann vom Integrator erweitert oder überschrieben und später durch
den Test-Runner. Dieser Mechanismus funktioniert für alle intrinsischen Java-Typen sowie für alle
Map- oder Collection-Werte unveränderlicher Typen.
Hinweis:Der Mechanismus der Optionenbehandlung funktioniert nur bei Klassen, in denen eine der Schnittstellen, die im Testlebenszyklus enthalten sind, und nur, wenn diese Klasse durch die Lebenszyklusmaschine instanziiert.
Entwickler
Zu Beginn markiert der Entwickler ein Mitglied mit der
@Option-Anmerkung.
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.
Nehmen wir als Beispiel an, wir möchten einen funktionalen Telefontest erstellen, mit dem eine Vielzahl von Telefonnummern und erwartet, von jeder nachfolgenden Nummer eine Folge von DTMF-Tönen zu erhalten verbindet.
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 auf die Konfiguration zu achten. Da die
@Option-Felder werden nach der Instanziierung der Klasse festgelegt, aber vor dem
run wird aufgerufen. Diese Methode bietet eine einfache Möglichkeit für Implementierer, Standardeinstellungen für
oder eine Art Filterung für die Felder Map und Collection durchführen, die
Andernfalls sind nur Anfügungen möglich.
Hersteller
Der Integrator arbeitet mit Konfigurationen, die in XML geschrieben sind. Konfigurationsformat
ermöglicht dem Integrator das Festlegen (oder Anfügen) eines Werts für ein beliebiges @Option-Feld. 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 ein Paar Konfigurationen erstellen,
etwa so aussehen:
<?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ührt er einen Befehl (d. h. eine Konfiguration und alle ihre Argumente) mit dem
Anweisung run command <name> (oder kurz run <name>).
Darüber hinaus können sie eine beliebige Liste von Argumenten im Befehl angeben, die oder
Anfügen an Felder, die durch Lebenszyklusobjekte in jeder Konfiguration angegeben sind.
Zum Ausführen des Tests mit niedriger Latenz mit den many-numbers-Telefonnummern benötigt der Test-Ausführer
ausführen könnten:
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-Ausführer die Wartezeit verkürzen
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
sodass alle --call in der Befehlszeile gespeichert werden.
Die Option timeout, der die Implementierung von long zugrunde liegt
kann nur einen Wert speichern. Es wird also nur der zuletzt angegebene Wert gespeichert.
--timeout 5 --timeout 10 ergibt timeout mit 10.
Bei einem List oder Collection als zugrunde liegende Implementierung
werden alle Werte in der in der Befehlszeile angegebenen Reihenfolge gespeichert.
Boolesche Optionen
Die Optionen des booleschen zugrunde liegenden Typs können auf true gesetzt werden, indem die
Optionsname, z. B. --[option-name], und kann mit false festgelegt werden.
die Syntax --no-[option-name].