La gestion des options est au cœur de l'approche modulaire de Trade Federation. En particulier, les options sont le mécanisme par lequel le développeur, l'intégrateur et le Test Runner peuvent travailler ensemble sans avoir à dupliquer le travail des autres. En d'autres termes, notre implémentation de la gestion des options permet au développeur de marquer un membre de classe Java comme configurable, auquel cas la valeur de ce membre peut être augmentée ou remplacée par l'intégrateur, puis augmentée ou remplacée par le Test Runner. Ce mécanisme fonctionne pour tous les types intrinsèques Java, ainsi que pour toutes les instances Map ou Collection de types intrinsèques.
Remarque : Le mécanisme de gestion des options ne fonctionne que pour les classes implémentant l'une des interfaces incluses dans le cycle de vie des tests, et uniquement lorsque cette classe est instanciée par le mécanisme du cycle de vie.
Développeur
Pour commencer, le développeur marque un membre avec l'annotation @Option.
Ils spécifient (au minimum) les valeurs name et description, qui indiquent le nom de l'argument associé à cette option et la description qui s'affiche dans la console TF lorsque la commande est exécutée avec --help ou --help-all.
Par exemple, supposons que nous voulions créer un test fonctionnel de téléphone qui compose différents numéros de téléphone et s'attend à recevoir une séquence de tonalités DTMF de chaque numéro après la connexion.
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 }
C'est tout ce dont le développeur a besoin pour configurer deux points de configuration pour ce test. Ils peuvent ensuite utiliser mWaitTime et mCalls normalement, sans prêter beaucoup d'attention au fait qu'ils sont configurables. Étant donné que les champs @Option sont définis après l'instanciation de la classe, mais avant l'appel de la méthode run, cela permet aux développeurs de configurer facilement des valeurs par défaut ou d'effectuer une sorte de filtrage sur les champs Map et Collection, qui sont sinon en mode ajout uniquement.
Intégrateur
L'intégrateur travaille dans le monde des configurations, qui sont écrites en XML. Le format de configuration permet à l'intégrateur de définir (ou d'ajouter) une valeur pour n'importe quel champ @Option. Par exemple, supposons que l'intégrateur souhaite définir un test à faible latence qui appelle le numéro par défaut, ainsi qu'un test de longue durée qui appelle différents numéros. Ils peuvent créer une paire de configurations qui peut ressembler à ce qui suit :
<?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>
Exécuteur de tests
Le Test Runner a également accès à ces points de configuration via la console Trade Federation.
Tout d'abord, ils exécutent une commande (c'est-à-dire une configuration et tous ses arguments) avec l'instruction run command <name> (ou run <name> en abrégé).
Au-delà, ils peuvent spécifier que toute liste d'arguments fait partie de la commande, ce qui peut remplacer ou ajouter des champs spécifiés par des objets de cycle de vie dans chaque configuration.
Pour exécuter le test à faible latence avec les numéros de téléphone many-numbers, le Test Runner peut exécuter :
tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#
Pour obtenir un effet similaire dans le sens inverse, le Test Runner peut réduire le temps d'attente pour le test many-numbers :
tf> run many-numbers.xml --timeout 5000
Ordre des options
Vous remarquerez peut-être que l'implémentation sous-jacente de l'option call est un Map. Par conséquent, toutes les commandes --call répétées sur la ligne de commande sont stockées.
L'option timeout, dont l'implémentation sous-jacente est long, ne peut stocker qu'une seule valeur. Seule la dernière valeur spécifiée est donc stockée.
--timeout 5 --timeout 10 donne timeout contenant 10.
En cas d'implémentation sous-jacente List ou Collection, toutes les valeurs sont stockées dans l'ordre spécifié sur la ligne de commande.
Options booléennes
Les options de type booléen sous-jacent peuvent être définies sur true en transmettant directement le nom de l'option, par exemple --[option-name], et peuvent être définies sur false à l'aide de la syntaxe --no-[option-name].