Optionen in Tradefed

Die Optionsverarbeitung ist ein zentraler Bestandteil des modularen Ansatzes von Trade Federation. Insbesondere sind Optionen der Mechanismus, mit dem Entwickler, Integrator und Test-Ausführer zusammenarbeiten können, ohne die Arbeit der anderen zu wiederholen. Einfach ausgedrückt ermöglicht unsere Implementierung der Optionsverarbeitung dem Entwickler, ein Java-Klassenmitglied als konfigurierbar zu markieren. Der Wert dieses Mitglieds kann dann vom Integrator ergänzt oder überschrieben werden und anschließend vom Test-Ausführer ergänzt oder überschrieben werden. Dieser Mechanismus funktioniert für alle nativen Java-Typen sowie für alle Map- oder Collection-Instanzen von nativen Typen.

Hinweis: Der Mechanismus zur Optionsverarbeitung 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 markiert der Entwickler ein Mitglied mit der Annotation @Option. Er gibt mindestens die Werte name und description an. Diese Werte geben den Argumentnamen an, der mit dieser Option verknüpft ist, und die Beschreibung, 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 funktionalen Telefontest erstellen, bei dem verschiedene Telefonnummern angerufen werden. Nach der Verbindung soll von jeder Nummer eine Sequenz von DTMF-Tönen empfangen werden.

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 tun muss, um zwei Konfigurationspunkte für diesen Test einzurichten. Er kann dann mWaitTime und mCalls wie gewohnt verwenden, ohne viel darauf zu achten, dass sie konfigurierbar sind. Da die @Option-Felder festgelegt werden, nachdem die Klasse instanziiert wurde, aber bevor die Methode run aufgerufen wird, können Implementierer auf einfache Weise Standardwerte festlegen oder eine Art Filterung für Map- und Collection-Felder durchführen, die andernfalls 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 jedes @Option-Feld festzulegen oder anzuhängen. Angenommen, der Integrator möchte einen Test mit niedrigerer Latenz definieren, bei dem die Standardnummer angerufen wird, sowie einen Test mit langer Laufzeit, bei dem verschiedene Nummern angerufen werden. Er könnte ein Paar Konfigurationen erstellen, die 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-Ausführer hat über die Trade Federation-Konsole auch Zugriff auf diese Konfigurationspunkte. Zuerst führt er einen Befehl (d. h. eine Konfiguration und alle zugehörigen Argumente) mit der run command <name> Anweisung (oder run <name> kurz) aus. Außerdem kann er eine beliebige Liste von Argumenten angeben, die Teil des Befehls sind. Diese können Felder ersetzen oder anhängen, die von Lebenszyklusobjekten in jeder Konfiguration angegeben werden.

Um den Test mit niedriger Latenz mit den Telefonnummern many-numbers auszuführen, kann der Test-Ausführer 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, kann der Test-Ausführer die Wartezeit für den Test many-numbers verkürzen:

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

Optionsreihenfolge

Die zugrunde liegende Implementierung der call Option ist eine Map . Wenn Sie also in der Befehlszeile wiederholt --call verwenden, werden alle Werte gespeichert.

Die Option timeout, deren zugrunde liegende Implementierung long ist, kann nur einen Wert speichern. Daher wird nur der zuletzt angegebene Wert gespeichert. --timeout 5 --timeout 10 führt dazu, dass timeout den Wert 10 enthält.

Wenn die zugrunde liegende Implementierung eine List oder Collection ist, werden alle Werte in der Reihenfolge gespeichert, in der sie in der Befehlszeile angegeben wurden.

Boolesche Optionen

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

Weitere Informationen