Gestione delle opzioni in TradeFed

La gestione delle opzioni è al centro dell'approccio modulare di Trade Federation. In particolare, le opzioni sono il meccanismo con cui lo sviluppatore, l'integratore e Test Runner possono collaborare senza dover duplicare il lavoro degli altri. In parole semplici, la nostra implementazione della gestione delle opzioni consente allo sviluppatore di 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 dal Test Runner. Questo meccanismo funziona per tutti i tipi intrinseci di Java, nonché per qualsiasi istanza Map o Collection di tipi intrinseci.

Nota:il meccanismo di gestione delle opzioni funziona solo per le classi che implementano una delle interfacce incluse nel ciclo di vita del test e solo quando la classe viene istanziata dal meccanismo del ciclo di vita.

Sviluppatore

Per iniziare, lo sviluppatore contrassegna un membro con l'annotazione @Option. Specificano (come minimo) i valori name e description, che specificano il nome dell'argomento associato a questa 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 funzionale del telefono che componga una serie di numeri di telefono e si aspetti di ricevere una sequenza di toni DTMF da ciascun numero dopo la connessione.

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 serve allo sviluppatore per configurare due punti di configurazione per questo test. Potrebbero quindi andare avanti e utilizzare mWaitTime e mCalls normalmente, senza prestare molta attenzione al fatto che sono configurabili. Poiché i campi @Option vengono impostati dopo l'istanza della classe, ma prima della chiamata al metodo run, ciò offre agli implementatori un modo semplice per impostare i valori predefiniti per o eseguire un qualche tipo di filtro sui campi Map e Collection, che altrimenti sono solo di accodamento.

Integrator

L'integratore opera 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 voglia definire un test a bassa latenza che chiami il numero predefinito, nonché un test a esecuzione prolungata che chiami una serie di numeri. Potrebbero creare una coppia di configurazioni che potrebbero 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

Test Runner ha accesso a questi punti di configurazione anche tramite la console Trade Federation. Innanzitutto, eseguono un comando (ovvero una configurazione e tutti i relativi argomenti) con l'istruzione run command <name> (o run <name> in breve). Inoltre, possono specificare qualsiasi elenco di argomenti che fanno parte del comando, che può sostituire o aggiungere campi specificati dagli oggetti del ciclo di vita all'interno di ogni configurazione.

Per eseguire il test a bassa latenza con i numeri di telefono many-numbers, Test Runner 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, Test Runner potrebbe ridurre il tempo di 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 vengono memorizzati tutti dopo ripetuti --call sulla riga di comando.

L'opzione timeout, che ha un'implementazione sottostante di long, può memorizzare un solo valore. Pertanto, viene memorizzato solo l'ultimo valore specificato. --timeout 5 --timeout 10 risultati in timeout contenenti 10.

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

Opzioni booleane

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

Vedi anche