Optionen in Tradefed

Die Optionenverwaltung steht im Mittelpunkt des modularen Ansatzes von Trade Federation. Insbesondere sind Optionen der Mechanismus, mit dem Entwickler, Integratoren und Testläufer zusammenarbeiten können, ohne sich gegenseitig die Arbeit zu duplizieren. Unsere Implementierung der Optionenverwaltung ermöglicht es dem Entwickler, ein Java-Klassenmitglied als konfigurierbar zu kennzeichnen. 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 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 mit dieser Option verknüpften Arguments und die Beschreibung angeben, die in der TF-Konsole angezeigt wird, 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 ist alles, was der Entwickler für die Einrichtung von zwei Konfigurationspunkten für diesen Test benötigt. Er kann dann mWaitTime und mCalls wie gewohnt verwenden, ohne viel Wert darauf zu legen, 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 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 sind. Mit dem Konfigurationsformat kann der Integrator einen Wert für jedes @Option-Feld festlegen (oder anhängen). Angenommen, der Integrator möchte einen Test mit niedrigerer Latenz definieren, der die Standardnummer aufruft, sowie einen langwierigen Test, der eine Vielzahl von Nummern aufruft. 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 Console Zugriff auf diese Konfigurationspunkte. In erster Linie führen sie einen Befehl (d. h. eine Konfiguration und alle zugehörigen Argumente) mit der Anweisung run command <name> (kurz run <name>) aus. Außerdem können sie eine Liste von Argumenten angeben, die Teil des Befehls sind. Diese können Felder ersetzen oder anhängen, die in den einzelnen Konfigurationen durch Lebenszyklusobjekte 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 in die entgegengesetzte 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

Sie werden feststellen, dass die zugrunde liegende Implementierung der call-Option eine Map ist. Wenn Sie also wiederholt --call in der Befehlszeile eingeben, werden 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 festgelegt werden, indem der Optionenname direkt übergeben wird, z. B. --[option-name]. Sie können auch mit der Syntax --no-[option-name] auf false festgelegt werden.

Siehe auch

Optionen an Suite und Module übergeben