Optionen in Tradefed

Die Verarbeitung von Optionen ist das Herzstück des modularen Ansatzes von Trade Federation. Insbesondere sind Optionen der Mechanismus, mit dem Entwickler, Integrator und Test Runner zusammenarbeiten können, ohne die Arbeit des jeweils anderen zu duplizieren. Einfach ausgedrückt: Mit unserer Implementierung der Optionsverarbeitung kann der Entwickler ein Java-Klassenmitglied als konfigurierbar markieren. Der Wert dieses Mitglieds kann dann vom Integrator ergänzt oder überschrieben und anschließend vom Test Runner ergänzt oder überschrieben werden. Dieser Mechanismus funktioniert für alle intrinsischen Java-Typen sowie für alle Map- oder Collection-Instanzen intrinsischer Typen.

Hinweis:Der Mechanismus zur Verarbeitung von Optionen funktioniert nur für Klassen, die eine der Schnittstellen implementieren, die im Testlebenszyklus enthalten sind, und nur, wenn diese Klasse von der Lebenszyklus-Maschinerie instanziiert wird.

Entwickler

Zuerst kennzeichnet der Entwickler ein Mitglied mit der Annotation @Option. Sie geben (mindestens) die Werte name und description an, die den Argumentnamen für diese Option und die Beschreibung angeben, die in der TF-Konsole angezeigt wird, wenn der Befehl mit --help oder --help-all ausgeführt wird.

Nehmen wir an, wir möchten einen Funktionstest für Telefone erstellen, bei dem verschiedene Telefonnummern gewählt werden und nach der Verbindung eine Reihe von DTMF-Tönen von jeder Nummer erwartet wird.

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 konnten dann mWaitTime und mCalls wie gewohnt verwenden, ohne viel darauf zu achten, dass sie konfigurierbar sind. 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 die Felder Map und Collection festlegen oder eine Art Filterung für diese Felder durchführen, die ansonsten nur angehängt werden können.

Integrator

Der Integrator arbeitet mit Konfigurationen, die in XML geschrieben sind. Das Konfigurationsformat ermöglicht es dem Integrator, einen Wert für ein beliebiges @Option-Feld festzulegen oder anzuhängen. Angenommen, der Integrator möchte einen Test mit niedriger Latenz definieren, bei dem die Standardnummer angerufen wird, sowie einen zeitaufwendigen Test, bei dem verschiedene Nummern angerufen werden. Sie könnten ein Konfigurationspaar erstellen, das so aussehen könnte:

<?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 über die Trade Federation-Konsole auch Zugriff auf diese Konfigurationspunkte. Zuerst führen sie einen Befehl (d. h. eine Konfiguration und alle zugehörigen Argumente) mit der Anweisung run command <name> (oder kurz run <name>) aus. Außerdem können sie eine beliebige Liste von Argumenten angeben, die Teil des Befehls sind und Felder ersetzen oder an Felder anhängen können, die von Lebenszyklusobjekten in jeder Konfiguration angegeben werden.

Um den Test mit geringer 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 für den many-numbers-Test verkürzen:

tf> run many-numbers.xml --timeout 5000

Reihenfolge der Optionen

Die zugrunde liegende Implementierung der Option call ist ein Map. Bei wiederholten --call in der Befehlszeile werden sie also alle gespeichert.

Die Option timeout, die auf der Implementierung von long basiert, kann nur einen Wert speichern. Es wird also nur der zuletzt angegebene Wert gespeichert. --timeout 5 --timeout 10 führt zu timeout mit dem Wert 10.

Bei einer List- oder Collection-Implementierung werden alle Werte in der Reihenfolge gespeichert, die in der Befehlszeile angegeben ist.

Boolesche Optionen

Optionen des zugrunde liegenden booleschen Typs können auf true gesetzt werden, indem der Optionsname direkt übergeben wird, z. B. --[option-name]. Sie können mit der Syntax --no-[option-name] auf false gesetzt werden.

Siehe auch