La gestione delle opzioni è al centro dell'approccio modulare di Trade Federation. In particolare, le opzioni
sono il meccanismo tramite il quale lo sviluppatore, l'integratore e il Test Runner possono lavorare insieme senza dover duplicare il lavoro l'uno dell'altro. In parole semplici, la nostra implementazione della gestione delle opzioni consente allo sviluppatore di contrassegnare un membro di una classe Java come configurabile, a quel punto il valore di quel membro può essere aumentato o ignorato dall'integratore e successivamente aumentato o ignorato 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 dalla struttura del ciclo di vita.
Sviluppatore
Per iniziare, lo sviluppatore contrassegna un membro con l'annotazione @Option.
Specificano (almeno) i valori name e description, che
specificano il nome dell'argomento associato all'opzione e la descrizione visualizzata sulla console TF quando il comando viene eseguito con --help o --help-all.
Ad esempio, supponiamo di voler creare un test di funzionalità telefonica che chiami una serie di numeri di telefono e si aspetti di ricevere una sequenza di toni DTMF da ogni 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 è 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 l'inizializzazione della classe, ma prima dell'esecuzione del metodo run, gli implementatori possono impostare facilmente i valori predefiniti o eseguire un tipo di filtro sui campi Map e Collection, che altrimenti sono di sola aggiunta.
Azienda integrativa
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 con latenza inferiore che chiami il numero predefinito, nonché un test di lunga durata che chiami una serie 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
Il Test Runner ha accesso anche a questi punti di configurazione 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> per breve).
Inoltre, possono specificare qualsiasi elenco di argomenti che fanno parte del comando, che può sostituire oaggiungere ai 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, il 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 in direzione opposta, il 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, 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. Pertanto, viene memorizzato 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 di tipo di base 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].