Gestion des options dans Tradefed

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 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 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écifient le nom de l'argument associé à cette option, ainsi que la description qui s'affiche sur la console TF lorsque la commande est exécutée avec --help ou --help-all.

Par exemple, imaginons que nous souhaitions créer un test téléphonique fonctionnel 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
    }

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 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 à latence réduite qui appelle le numéro par défaut, ainsi qu'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>

Exécuteur de test

Le Test Runner a également accès à ces points de configuration via la console de la 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> pour faire court). En outre, 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 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 opposé, le testeur de test 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. Par conséquent, en cas de --call répétés 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. Seule la dernière valeur spécifiée est donc stockée. --timeout 5 --timeout 10 fournit un résultat égal à 10 dans timeout.

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 sous-jacent booléen 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].

Voir aussi