Gestione delle opzioni in TradeFed

La gestione delle opzioni è al centro dell'approccio modulare di Trade Federation. In particolare, le opzioni sono il meccanismo mediante il quale sviluppatore, integratore e test runner possono collaborare senza dover duplicare il lavoro reciproco. In parole povere, la nostra implementazione della gestione delle opzioni consente sviluppatore per contrassegnare un membro della classe Java come configurabile, a quel punto il valore di quel membro può essere aumentato o sostituito dall'integratore e può essere successivamente aumentato o sostituito l'esecutore del test. Questo meccanismo funziona per tutti i tipi intrinseci Java, nonché per qualsiasi Map o Collection istanze di tipi intrinseci.

Nota: il meccanismo di gestione delle opzioni funziona solo per i corsi. implementare uno dei interfacce incluse nel ciclo di vita dei test e solo quando la classe è basato dai macchinari del ciclo di vita.

Sviluppatore

Per iniziare, lo sviluppatore contrassegna un membro con Annotazione @Option. Specificano (come minimo) i valori name e description, che specificano il nome dell'argomento associato all'opzione e la descrizione visualizzata nella console TF quando il comando viene eseguito con --help o --help-all.

Ad esempio, supponiamo di voler creare un test telefonico che consenta di numeri di telefono e si aspetta di ricevere una sequenza di toni DTMF da ogni numero dopo si connette.

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
    }

È tutto ciò che è necessario per consentire allo sviluppatore di configurare due punti di configurazione per il test. Potrebbero quindi utilizzare mWaitTime e mCalls come al solito, senza prestare molta attenzione al fatto che sono configurabili. Poiché I campi @Option vengono impostati dopo la creazione dell'istanza del corso, ma prima del Viene chiamato il metodo run, che consente agli implementatori di configurare facilmente i valori predefiniti per o eseguire un qualche tipo di filtro sui campi Map e Collection, che sono altrimenti in sola aggiunta.

Azienda integrativa

L'integratore funziona nel mondo delle configurazioni, che sono scritte in XML. Il formato di configurazione consente all'integratore di impostare (o aggiungere) un valore per qualsiasi campo @Option. Ad esempio, supponiamo che l'integratore volesse definire un test a latenza inferiore che chiami anche il numero predefinito, è un test a lungo termine che chiama una varietà di numeri. Potrebbe creare una coppia di configurazioni che potrebbe avere il seguente aspetto:

<?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 Runner

L'esecutore del test ha accesso anche a questi punti di configurazione tramite la console della Trade Federation. Innanzitutto, eseguono un comando (ovvero una configurazione e tutti i suoi argomenti) con run command <name> (o run <name> in breve). Inoltre, possono specificare qualsiasi elenco di argomenti del comando, che può sostituire aggiungere ai campi specificati da oggetti del ciclo di vita all'interno di ogni configurazione.

Per eseguire il test a bassa latenza con i numeri di telefono many-numbers, utilizza l'esecutore del test potrebbe eseguire:

tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#

In alternativa, per ottenere un effetto simile dalla direzione opposta, il responsabile del test potrebbe ridurre l'attesa per il test many-numbers:

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

Ordinamento delle opzioni

Potresti notare che l'implementazione sottostante dell'opzione call è un Map quindi, dopo ripetuti --call sulla riga di comando, vengono tutti memorizzati.

L'opzione timeout, che ha un'implementazione sottostante di long, può memorizzare un solo valore. Di conseguenza, viene archiviato solo l'ultimo valore specificato. --timeout 5 --timeout 10 genera timeout contenente 10.

In caso di List o Collection come implementazione di base, tutti i valori vengono memorizzati nell'ordine specificato nella riga di comando.

Opzioni booleane

Le opzioni del tipo sottostante booleano possono essere impostate su true trasmettendo direttamente il valore nome dell'opzione, ad esempio --[option-name] e può essere impostato su false utilizzando la sintassi --no-[option-name].

Vedi anche