La gestion des options est au cœur de l'approche modulaire de la Trade Federation. En particulier, les options constituent le mécanisme par lequel le développeur, l'intégrateur et l'exécuteur de test 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, auquel cas la valeur de ce membre peut être augmentée ou remplacée par l'intégrateur, et peut ensuite être augmentée ou remplacée par le Test Runner. Ce mécanisme fonctionne pour tous les types intrinsèques Java, ainsi que pour tous 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 Test Lifecycle , et uniquement lorsque cette classe est instanciée par la machinerie 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 spécifient le nom de l'argument associé à cette option, ainsi que la description qui sera affichée sur la console TF lorsque la commande est exécutée avec --help ou --help-all .
À titre d'exemple, disons que nous souhaitons créer un test téléphonique fonctionnel qui composera une variété de numéros de téléphone et s'attendra à 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 mettre en place deux points de configuration pour ce test. Ils pourraient alors 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 offre aux implémenteurs un moyen simple de définir des valeurs par défaut ou d'effectuer une sorte de filtrage sur les champs Map et Collection , qui sont autrement ajoutés. seulement.
Intégrateur
L'intégrateur travaille dans le monde des configurations, é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 veuille définir un test à faible latence qui appelle le numéro par défaut, ainsi qu'un test de longue durée qui appelle une variété de numéros. Ils pourraient créer une paire de configurations qui pourraient 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>
Testeur
Le Test Runner a également accès à ces points de configuration via la console Trade Federation. Tout d'abord, ils exécuteront 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à de cela, ils peuvent spécifier n'importe quelle liste d'arguments faisant partie de la commande, qui peut remplacer ou ajouter des champs spécifiés par les 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 , Test Runner peut exécuter :
tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#
Ou, pour obtenir un effet similaire dans la direction opposée, le Test Runner pourrait réduire le temps d'attente pour le test many-numbers :
tf> run many-numbers.xml --timeout 5000
Commande d'options
Vous remarquerez peut-être que l'option call sous-jacente à l'implémentation est une Map , donc lors d'un --call répété sur la ligne de commande, ils seront tous stockés.
L'option timeout , qui a une implémentation sous-jacente de long , ne peut stocker qu'une seule valeur. Ainsi, seule la dernière valeur spécifiée sera stockée. --timeout 5 --timeout 10 entraînera un timeout contenant 10.
Dans le cas d'une List ou Collection comme implémentation sous-jacente, toutes les valeurs seront stockées, dans l'ordre spécifié sur la ligne de commande.
Options booléennes
Les options de type sous-jacent booléen peuvent être définies sur true en passant directement le nom de l'option, par exemple --[option-name] et peuvent être définies sur false en utilisant la syntaxe --no-[option-name] .