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.