La gestione delle opzioni è al centro dell'approccio modulare della Trade Federation. In particolare, le opzioni sono il meccanismo attraverso il quale lo Sviluppatore, l'Integratore e il Test Runner possono lavorare insieme senza dover duplicare il lavoro dell'altro. In parole povere, 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 sovrascritto dall'integratore e può essere successivamente aumentato o sovrascritto dal Test Runner. Questo meccanismo funziona per tutti i tipi intrinseci Java, nonché per qualsiasi Map o Collection s di tipi intrinseci.
Nota: il meccanismo di gestione delle opzioni funziona solo per le classi che implementano una delle interfacce incluse in Test Lifecycle e solo quando tale classe viene istanziata dal macchinario del ciclo di vita.
Sviluppatore
Per iniziare, lo sviluppatore contrassegna un membro con l'annotazione @Option . Specificano (come minimo) i valori del name e della description , che specificano il nome dell'argomento associato a quell'opzione e la descrizione che verrà visualizzata sulla console TF quando il comando viene eseguito con --help o --help-all .
Ad esempio, supponiamo di voler costruire un test del telefono funzionale che comporrà una varietà di numeri di telefono e si aspetterà di ricevere una sequenza di toni DTMF da ciascun numero dopo che si è connesso.
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
}
Questo è tutto ciò che è richiesto allo sviluppatore per impostare due punti di configurazione per quel test. Potrebbero quindi spegnersi e utilizzare mWaitTime e mCalls normalmente, senza prestare molta attenzione al fatto che sono configurabili. Poiché i campi @Option vengono impostati dopo che la classe è stata istanziata, ma prima che venga chiamato il metodo run , ciò fornisce agli implementatori un modo semplice per impostare i valori predefiniti o eseguire una sorta di filtro sui campi Map e Collection , che altrimenti sarebbero aggiunti. solo.
Integratore
L'integratore lavora 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 bassa latenza che chiama il numero predefinito, nonché un test di lunga durata che chiama una varietà di numeri. Potrebbero creare un paio di configurazioni che potrebbero essere simili alle seguenti:
<?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>
Corridore di prova
Il Test Runner ha anche accesso a questi punti di configurazione tramite la console della Trade Federation. Innanzitutto, eseguiranno un comando (ovvero, una configurazione e tutti i suoi argomenti) con l'istruzione run command <name> (o run <name> in breve). Oltre a ciò, possono specificare qualsiasi elenco di argomenti che fanno parte del comando, che può sostituire o aggiungere campi specificati da Lifecycle Objects all'interno di ogni configurazione.
Per eseguire il test a bassa latenza con i many-numbers telefono a più numeri, il Test Runner potrebbe eseguire:
tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#
Oppure, per ottenere un effetto simile dalla direzione opposta, il Test Runner potrebbe ridurre il tempo di attesa per il test many-numbers :
tf> run many-numbers.xml --timeout 5000
Ordinazione delle opzioni
Potresti notare che l'opzione call alla base dell'implementazione è una Map , quindi dopo aver ripetuto --call sulla riga di comando verranno tutti archiviati.
L'opzione timeout , che ha un'implementazione sottostante di long , può memorizzare solo un valore. Quindi verrà memorizzato solo l'ultimo valore specificato. --timeout 5 --timeout 10 risulterà in un timeout contenente 10.
In caso di List o Collection come implementazione sottostante, tutti i valori verranno archiviati, nell'ordine specificato nella riga di comando.
Opzioni booleane
Le opzioni di 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] .