La gestion des options est au cœur de l'approche modulaire de la fédération du commerce. En particulier, les options
sont les mécanismes permettant au développeur, à l'intégrateur et au lanceur de test de travailler ensemble sans
de devoir dupliquer
le travail de chacun. En termes simples, notre implémentation
de la gestion des options permet
Le développeur doit marquer un membre de la classe Java comme configurable, auquel cas la valeur de ce membre
peuvent être augmentées ou remplacées par l'intégrateur, puis peuvent être augmentées ou remplacées par la suite
le lanceur de test. Ce mécanisme fonctionne pour tous les types intrinsèques de Java, ainsi que pour toutes
Objets Map ou Collection de types intrinsèques.
Remarque:Le mécanisme de gestion des options ne fonctionne que pour les classes qui implémentent l'un des incluses dans le cycle de vie des tests, et uniquement lorsque cette classe est instanciés par les machines du cycle de vie.
Développeur
Pour commencer, le développeur marque un membre avec le
Annotation @Option.
Ils spécifient (au minimum) les valeurs name et description, qui
Spécifiez le nom d'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.
Par exemple, imaginons que nous voulions créer un test fonctionnel pour téléphoner numéros de téléphone, et s'attendra à recevoir une séquence de tonalités DTMF provenant de 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
}
C'est tout ce dont le développeur a besoin pour définir deux points de configuration pour cette
test. Ils pourraient ensuite utiliser mWaitTime et mCalls normalement,
sans prêter beaucoup d'attention
au fait qu'ils peuvent être configurés. En effet,
Les champs @Option sont définis après l'instanciation de la classe, mais avant la
La méthode run est appelée, ce qui permet aux développeurs de configurer facilement des valeurs par défaut pour
ou filtrer les champs Map et Collection, qui sont
sinon "append-only".
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 pourrait se présenter 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.
En premier lieu, ils exécuteront 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
ajoute 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*#*#
Ou, pour obtenir un effet similaire dans la direction opposée, le lanceur de test peut réduire le temps d’attente
pour le test many-numbers:
tf> run many-numbers.xml --timeout 5000
Ordonnancement des options
Vous remarquerez peut-être que l'implémentation sous-jacente de l'option call est un Map.
Par conséquent, si les données --call sont répétées sur la ligne de commande, elles sont toutes stockées.
L'option timeout, avec 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.
Avec --timeout 5 --timeout 10, timeout contiendra 10.
Dans le cas d'une List ou d'un 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 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].