Obsługa opcji w Tradefed

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Obsługa opcji jest podstawą podejścia modułowego Trade Federation. W szczególności opcje to mechanizm, dzięki któremu programista, Integrator i Test Runner mogą współpracować bez konieczności dublowania pracy. Mówiąc w prosty sposób, nasze rozwiązanie do obsługi opcji pozwala deweloperowi oznaczyć element klasy Java jako konfigurowalny. Oznacza to, że jego wartość może zostać rozszerzona lub zastąpiona przez Integratora, a następnie rozszerzona lub zastąpiona przez Test Runnera. Ten mechanizm działa w przypadku wszystkich typów niestandardowych w języku Java, a także w przypadku dowolnych instancji typów niestandardowych Map lub Collection.

Uwaga: mechanizm obsługi opcji działa tylko w przypadku klas implementujących jeden z interfejsów zawartych w cyklu testowania. Działa on tylko wtedy, gdy klasa jest tworzona przez mechanizm cyklu życia.

Programista

Na początek deweloper oznacza użytkownika adnotacją @Option. Określają one (co najmniej) wartości name i description, które określają nazwę argumentu powiązanego z opcją, oraz opis wyświetlany w konsoli TF, gdy polecenie jest wykonywane za pomocą opcji --help lub --help-all.

Załóżmy, że chcemy utworzyć funkcjonalny test telefonu, który wybiera różne numery telefonów i po połączeniu oczekuje sekwencji DTMF z każdego z nich.

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
    }

To wszystko, czego deweloper potrzebuje do skonfigurowania 2 punktów konfiguracji na potrzeby testu. Mogą wtedy normalnie używać funkcji mWaitTime i mCalls, nie zwracając uwagi na fakt, że można je konfigurować. Pola @Option są ustawiane po utworzeniu instancji klasy, ale przed wywołaniem metody run. Dzięki temu implementatorzy mogą łatwo skonfigurować wartości domyślne lub przeprowadzić filtrowanie pól Map i Collection, które są w innym przypadku tylko do dołączania.

Producent

Integrator działa w świecie konfiguracji, które są zapisane w formacie XML. Format konfiguracji umożliwia Integratorowi ustawienie (lub dodanie) wartości w dowolnym polu @Option. Załóżmy na przykład, że Integrator chce zdefiniować test o krótszym opóźnieniu, który wywołuje numer domyślny, a także długotrwały test, który wywołuje różne numery. Może on utworzyć parę konfiguracji, które wyglądają tak:

<?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>

Uruchamiający test

Test Runner ma też dostęp do tych punktów konfiguracji w konsoli Trade Federation. Przede wszystkim uruchamiają one polecenie (czyli konfigurację i wszystkie jej argumenty) za pomocą instrukcji run command <name> (czyli w skrócie run <name>). Mogą też podać dowolną listę argumentów jako część polecenia, które może zastąpić lub dodać do pól określonych przez obiekty cyklu życia w każdej konfiguracji.

Aby przeprowadzić test o niskim opóźnieniu z użyciem numerów telefonów many-numbers, Test Runner może wykonać:

tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#

Aby uzyskać podobny efekt w przeciwnym kierunku, Test Runner może skrócić czas oczekiwania dla testu many-numbers:

tf> run many-numbers.xml --timeout 5000

Kolejność opcji

Możesz zauważyć, że opcja call implementacji jest Map, więc po powtórzeniu --call w wierszu poleceń wszystkie są przechowywane.

Opcja timeout, która ma implementację podrzędną long, może przechowywać tylko jedną wartość. Dlatego przechowywana jest tylko ostatnia wartość. --timeout 5 --timeout 10 wyników w timeout zawierających 10.

W przypadku List lub Collection jako implementacji podstawowej wszystkie wartości są przechowywane w kolejności podanej w wierszu poleceń.

Opcje wartości logicznych

Opcje typu logicznego można ustawić jako true, podając bezpośrednio nazwę opcji, np. --[option-name], i można je ustawić jako false, używając składni --no-[option-name].

Zobacz również