La gestione delle opzioni è al centro dell'approccio modulare di Trade Federation. In particolare, le opzioni sono il meccanismo mediante il quale lo sviluppatore, l'integratore e il test runner possono collaborare 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 di tipi intrinseci.
Nota: il meccanismo di gestione delle opzioni funziona solo per le classi che implementano una delle interfacce incluse nel Test Lifecycle e solo quando quella classe viene istanziata dal macchinario del ciclo di vita.
Sviluppatore
Per iniziare, lo sviluppatore contrassegna un membro con l'annotazione @Option . Specificano (come minimo) il name e i valori description , che specificano il nome dell'argomento associato a tale 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 creare un test telefonico funzionale che comporrà una varietà di numeri di telefono e si aspetterà 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
}
Questo è tutto ciò che serve allo sviluppatore per impostare due punti di configurazione per quel test. Potrebbero quindi utilizzare mWaitTime e mCalls normalmente, senza prestare molta attenzione al fatto che sono configurabili. Poiché i campi @Option vengono impostati dopo l'istanziazione della classe, ma prima che venga chiamato il metodo run , ciò fornisce agli implementatori un modo semplice per impostare valori predefiniti o eseguire qualche tipo di filtro sui campi Map e Collection , che altrimenti sarebbero aggiunti soltanto.
Integratore
L'Integrator 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 . Supponiamo, ad esempio, che l'integratore voglia definire un test a latenza inferiore che chiami il numero predefinito, nonché un test a lunga esecuzione che chiami una varietà di numeri. Potrebbero creare una coppia di configurazioni che potrebbero assomigliare 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 accesso a questi punti di configurazione anche tramite la console della Federazione dei Mercanti. 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 ai campi specificati da Lifecycle Objects all'interno di ciascuna configurazione.
Per eseguire il test a bassa latenza con i numeri di telefono many-numbers , il Test Runner può 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 sottostante l'implementazione è una Map , quindi dopo aver ripetuto --call sulla riga di comando verranno tutte archiviate.
L'opzione timeout , che ha un'implementazione sottostante di long , può memorizzare solo un valore. Pertanto verrà memorizzato solo l'ultimo valore specificato. --timeout 5 --timeout 10 risulterà in timeout contenente 10.
In caso di List o Collection come implementazione sottostante, tutti i valori verranno archiviati, nell'ordine specificato sulla riga di comando.
Opzioni booleane
Le opzioni di tipo booleano sottostante 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] .