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 testeur peuvent travailler ensemble sans avoir à dupliquer le travail de chacun. En termes simples, notre implémentation de la gestion des options permet au développeur de marquer un membre de classe Java comme étant configurable. À ce stade, la valeur de ce membre peut être augmentée ou remplacée par l'intégrateur, puis augmentée ou remplacée par le testeur. Ce mécanisme fonctionne pour tous les types intrinsèques de Java, ainsi que pour toutes
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 de 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
spécifier le nom d'argument associé à cette option, ainsi que la description affichée sur
la console TF lorsque la commande est exécutée avec --help ou --help-all.
Par exemple, imaginons que nous voulions créer un test fonctionnel pour téléphoner numéros de téléphone, et s'attend à recevoir une suite de tonalités DTMF pour chaque numéro entre les réseaux.
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 }
Il ne suffit que de cela au développeur pour configurer deux points de configuration pour ce test. Il peut ensuite utiliser mWaitTime et mCalls comme d'habitude, 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, les implémentateurs peuvent facilement configurer des valeurs par défaut ou effectuer un filtrage sur les champs Map et Collection, qui ne sont autrement que des champs d'ajout.
Intégrateur
L'intégrateur fonctionne dans l'univers des configurations, qui sont écrites en XML. Format de la 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 veuille définir un test à faible latence qui appelle le numéro par défaut, ainsi que
comme un test de longue durée
qui appelle différents numéros. Il peut créer une paire de configurations qui se présente comme 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>
Test Runner
L'exécuteur de test a également accès à ces points de configuration via la console de fédération de commerce.
Avant tout, ils exécutent une commande (c'est-à-dire une configuration et tous ses arguments) avec la commande
Instruction run command <name> (ou run <name> en abrégé).
En outre, ils peuvent spécifier n'importe quelle liste d'arguments faisant partie de la commande, qui peut remplacer ou
ajouter aux champs spécifiés par les objets Lifecycle dans chaque configuration.
Pour exécuter le test à faible latence avec les numéros de téléphone many-numbers, le lanceur de test
pourrait exécuter:
tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#
Pour obtenir un effet similaire dans la direction opposée, le Test Runner peut réduire le temps d'attente du 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.
Ainsi, en cas de répétition d'--call sur la ligne de commande, ils sont tous stockés.
L'option timeout, qui dispose d'une implémentation sous-jacente de long, ne peut stocker qu'une seule valeur. Ainsi, seule la dernière valeur spécifiée est stockée.
--timeout 5 --timeout 10 renvoie timeout contenant 10.
Dans le cas d'une List ou d'un Collection comme implémentation sous-jacente,
toutes les valeurs sont stockées, dans l'ordre spécifié sur la ligne de commande.
Options booléennes
Les options du type sous-jacent booléen peuvent être définies sur true en transmettant directement le
nom de l'option (par exemple, --[option-name]) et peut être défini sur false à l'aide de
la syntaxe --no-[option-name].