Pisanie kodu uruchomienia testów Tradefed

Na tej stronie znajdziesz opis, jak napisać nowego wykonawcę testów w Tradefed.

Tło

Jeśli chcesz dowiedzieć się więcej o miejscu, jakie testy mają w architekturze Tradefed, zapoznaj się z artykułem Struktura testu testów.

Nie jest to warunek wstępny dla napisania nowego narzędzia do testowania. Narzędzie do testowania można napisać niezależnie.

Minimalne wymagania: wdrożenie interfejsu

Minimalnym wymogiem, aby spełniać kryteria testowania zdalnego, jest implementacja interfejsu IRemoteTest, a w szczególności metody run(TestInformation testInfo, ITestInvocationListener listener).

Ta metoda jest wywoływana przez narzędzie testowe podczas uruchamiania testu, podobnie jak metoda Runnable w języku Java.

Każda część tej metody jest uważana za część uruchomienia uruchamiania testów.

Raportuj wyniki z testera

Metoda run w interfejsie podstawowym zapewnia dostęp do obiektu listenera typu ITestInvocationListener. Ten obiekt jest kluczem do raportowania uporządkowanych wyników z testu do sterownika.

Raportując uporządkowane wyniki, osoba wykonująca test ma te właściwości:

  • raportuje odpowiednią listę wszystkich przeprowadzonych testów, ich czas trwania oraz informacje o tym, czy poszczególne testy zakończyły się powodzeniem, niepowodzeniem czy w innym stanie;
  • W razie potrzeby raportuj dane powiązane z testami, np. dane dotyczące czasu instalacji.
  • Dopasowywać się do większości narzędzi infrastrukturalnych, np. wyświetlać wyniki i dane.
  • Zwykle łatwiej je debugować, ponieważ dają bardziej szczegółowy ślad wykonania.

Raportowanie uporządkowanych wyników jest opcjonalne. Osoba uruchamiająca test może po prostu ocenić stan całego procesu jako „ZALECONY” lub „NIEZALECONY” bez żadnych szczegółów dotyczących faktycznego wykonania.

Te zdarzenia mogą być wywoływane do detektora, aby powiadamiać użytkownika o bieżącym postępie wykonań:

  • testRunStarted: powiadamia o początku grupy powiązanych ze sobą przypadków testowych.
    • testStarted: powiadamia o rozpoczęciu przypadku testowego.
    • testFailed/testIgnored: powiadomienie o zmianie stanu testu w trakcie. Przypadek testowy bez zmiany stanu jest uznawany za zaliczony.
    • testEnded: powiadamia o zakończeniu testu.
  • testRunFailed: powiadomienie o tym, że ogólny stan wykonania grupy przypadków testowych to błąd. Test może być zaliczony lub niezaliczony niezależnie od wyników przypadków testowych, w zależności od tego, czego oczekuje się od wykonania. Na przykład binarny plik wykonywalny z kilkoma przypadkami testowymi może zgłosić wszystkie przypadki testowe jako pozytywny, ale z błędnym kodem zakończenia (z dowolnych powodów, np. wyciek plików).
  • testRunEnded: powiadom koniec grupy przypadków testowych.

Za utrzymanie i zapewnienie prawidłowej kolejności wywołań metod wywołujących odpowiada implementator narzędzia do uruchamiania testów. Musi on na przykład zadbać o to, aby metoda testRunEnded była wywoływana w przypadku wyjątku z użyciem klauzuli finally.

Wywołania zwrotne testów (testStarted, testEnded itd.) są opcjonalne. Test może być wykonywany bez żadnych przypadków testowych.

Ta struktura zdarzeń jest inspirowana typową strukturą JUnit. Ma to na celu ukazanie podstawowych informacji, na temat których programiści zwykle wiedzą.

Raportowanie dzienników z testu

Jeśli piszesz własną klasę testu lub narzędzie do testowania Tradefed, zaimplementujesz interfejs IRemoteTest i uzyskasz obiekt ITestInvocationListener za pomocą metody run(). Można go używać do rejestrowania plików w ten sposób:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Testowanie na urządzeniu

Minimalny interfejs umożliwia uruchamianie bardzo prostych testów, które są izolowane i nie wymagają żadnych konkretnych zasobów, na przykład testów jednostkowych Java.

Autorzy testów, którzy chcą przejść do następnego etapu testowania urządzeń, będą potrzebować tych interfejsów:

  • IDeviceTest umożliwia otrzymanie obiektu ITestDevice, który reprezentuje testowane urządzenie, oraz zapewnia interfejs API do interakcji z tym urządzeniem.
  • IBuildReceiver pozwala testowi uzyskać obiekt IBuildInfo utworzony w etap dostawcy buildu, zawierający wszystkie informacje i artefakty związane z konfiguracją testu.

Te interfejsy są zwykle interesujące dla osób uruchamiających testy, ponieważ umożliwiają uzyskiwanie artefaktów związanych z wykonaniem, np. dodatkowych plików, oraz urządzeń testowych, które będą celem podczas wykonywania testu.

Testowanie na wielu urządzeniach

W ramach Tradefed można przeprowadzać testy na wielu urządzeniach jednocześnie. Jest to przydatne przy testowaniu komponentów, które wymagają interakcji zewnętrznej, np. parowania telefonu z zegarkiem.

Aby napisać test runner, który może używać wielu urządzeń, musisz zaimplementować interfejs IMultiDeviceTest, który umożliwi otrzymanie mapy ITestDevice na IBuildInfo zawierającej pełną listę reprezentacji urządzeń i powiązanych informacji o kompilacji.

Setter z interfejsu zawsze będzie wywoływany przed metodą run, więc można założyć, że struktura będzie dostępna, gdy zostanie wywołana metoda run.

testy z uwzględnieniem konfiguracji,

Niektóre implementacje testów mogą wymagać informacji o całym skonfigurowaniu, aby działać prawidłowo. Mogą to być na przykład metadane dotyczące wywołania lub informacje o tym, które target_preparer zostały uruchomione wcześniej.

Aby to osiągnąć, test runner może uzyskać dostęp do obiektu IConfiguration, którego jest częścią i w którym jest wykonywany. Więcej informacji znajdziesz w opisie obiektu konfiguracji.

W przypadku implementacji testu uruchamiającego musisz zaimplementować interfejs IConfigurationReceiver, aby odbierać obiekt IConfiguration.

Elastyczny testujący

Uruchamianie testów może być elastyczne, jeśli mają one precyzyjną kontrolę nad testami. Na przykład uruchamiany test JUnit może osobno uruchamiać poszczególne testy jednostkowe.

Dzięki temu większa infrastruktura i sprzęt mogą korzystać z tej precyzyjnej kontroli, a użytkownicy mogą uruchamiać częściowo narzędzie do testowania za pomocą filtrowania.

Obsługa filtrowania jest opisana w interfejsie ITestFilterReceiver, który umożliwia odbiór zestawów filtrów include i exclude dla testów, które powinny lub nie powinny być wykonywane.

Zgodnie z naszą konwencją przeprowadzany jest test, który pasuje do co najmniej jednego filtra uwzględniania ORAZ nie pasuje do żadnego z filtrów wykluczania. Jeśli nie podasz żadnych filtrów uwzględniających, wszystkie testy powinny być uruchamiane, o ile nie pasują do żadnego z filtrów wykluczających.