Ta strona opisuje, jak napisać nowego biegacza testowego w Tradefed.
Tło
Jeśli interesuje Cię miejsce biegaczy testowych w architekturze Tradefed, zobacz Struktura biegacza testowego .
Nie jest to warunek wstępny do napisania nowego biegacza testowego; biegacze testowi mogą być napisane w izolacji.
Absolutne minimum: Implementacja interfejsu
Podstawowym minimum, aby zakwalifikować się jako program uruchamiający testy Tradefed, jest zaimplementowanie interfejsu IRemoteTest, a dokładniej metody run(TestInformation testInfo, ITestInvocationListener listener) .
Ta metoda jest wywoływana przez uprząż podczas korzystania z programu uruchamiającego test, podobnie jak Java Runnable.
Każda część tej metody jest uważana za część wykonania programu uruchamiającego test.
Raportowanie wyników od uczestnika testu
Metoda run w interfejsie podstawowym daje dostęp do obiektu nasłuchiwania typu ITestInvocationListener . Ten obiekt jest kluczem do raportowania uporządkowanych wyników z testera do uprzęży.
Dzięki raportowaniu uporządkowanych wyników biegacz testowy ma następujące właściwości:
- Podaj odpowiednią listę wszystkich testów, które się odbyły, jak długo trwały i czy pojedynczo zdały, nie zaliczyły lub inne stany.
- Raportuj metryki związane z testami, jeśli ma to zastosowanie, na przykład metryki czasu instalacji.
- Dopasuj większość narzędzi infrastruktury, na przykład wyświetlaj wyniki i metryki itp.
- Zwykle łatwiejsze do debugowania, ponieważ istnieje bardziej szczegółowy ślad wykonania.
To powiedziawszy, raportowanie uporządkowanych wyników jest opcjonalne; biegacz testowy może po prostu chcieć ocenić stan całego biegu jako ZALICZONY lub NIEUDANY, bez żadnych szczegółów rzeczywistego wykonania.
UWAGA: Trudniej jest wdrożyć biegacza, który podąża za sekwencją wydarzeń, ale zalecamy to, biorąc pod uwagę wymienione powyżej korzyści.
Następujące zdarzenia mogą być wywoływane na odbiorniku, aby powiadomić uprząż o bieżącym postępie wykonywania:
- testRunStarted: Powiadom początek grupy przypadków testowych, które są ze sobą powiązane.
- testStarted: Powiadamia o początku uruchomienia przypadku testowego.
- testFailed/testIgnored: Powiadom o zmianie stanu przypadku testowego w toku. Przypadek testowy bez zmiany stanu jest uważany za zaliczony.
- testEnded: Powiadom o końcu przypadku testowego.
- testRunFailed: Powiadom, że ogólny stan grupy wykonania przypadków testowych to niepowodzenie. Przebieg testowy może być pomyślny lub niepomyślny , niezależnie od wyników przypadków testowych, w zależności od tego, czego oczekiwało wykonanie. Na przykład plik binarny, w którym uruchomiono kilka przypadków testowych, może zgłaszać wszystkie pomyślne przypadki testowe, ale z kodem zakończenia błędu (z dowolnych powodów: wyciekły pliki itp.).
- testRunEnded: Powiadamia o końcu grupy przypadków testowych.
Za utrzymanie i zapewnienie właściwej kolejności wywołań zwrotnych odpowiada implementator programu uruchamiającego testy, na przykład za zapewnienie, że testRunEnded jest wywoływany w przypadku wyjątku przy użyciu klauzuli finally .
Wywołania zwrotne przypadków testowych ( testStarted , testEnded , itp.) są opcjonalne. Przebieg testowy może nastąpić bez żadnych przypadków testowych.
Możesz zauważyć, że ta struktura wydarzeń jest inspirowana typową strukturą JUnit . Jest to celowe, aby utrzymać rzeczy w pobliżu czegoś podstawowego, o czym programiści zwykle mają wiedzę.
Zgłaszanie dzienników od biegacza testowego
Jeśli piszesz własną klasę testową lub program uruchamiający Tradefed, zaimplementujesz IRemoteTest i uzyskasz ITestInvocationListener za pomocą metody run() . Ten detektor może być używany do rejestrowania plików w następujący sposób:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Testowanie za pomocą urządzenia
Minimalny interfejs powyżej pozwala na uruchamianie bardzo prostych testów, które są izolowane i nie wymagają żadnych szczególnych zasobów, na przykład testy jednostkowe Java.
Twórcy testów, którzy chcą przejść do następnego etapu testowania urządzeń, będą potrzebować następujących interfejsów:
- IDeviceTest umożliwia otrzymanie obiektu
ITestDevice, który reprezentuje testowane urządzenie i udostępnia interfejs API do interakcji z nim. - IBuildReceiver umożliwia testowi pobranie obiektu
IBuildInfoutworzonego na etapie dostawcy kompilacji zawierającego wszystkie informacje i artefakty związane z konfiguracją testu.
Osoby uruchamiające testy są zwykle zainteresowane tymi interfejsami, aby uzyskać artefakty związane z wykonaniem, na przykład dodatkowe pliki, i uzyskać testowane urządzenie, które będzie celem podczas wykonywania.
Testowanie na wielu urządzeniach
Tradefed obsługuje uruchamianie testów na wielu urządzeniach jednocześnie. Jest to przydatne podczas testowania komponentów wymagających zewnętrznej interakcji, takich jak parowanie telefonu i zegarka.
Aby napisać program uruchamiający testy, który może korzystać z wielu urządzeń, będziesz musiał zaimplementować IMultiDeviceTest , który pozwoli na otrzymanie mapy ITestDevice do IBuildInfo , która zawiera pełną listę reprezentacji urządzeń i skojarzone z nimi informacje o kompilacji.
Setter z interfejsu będzie zawsze wywoływany przed metodą run , więc można bezpiecznie założyć, że struktura będzie dostępna po wywołaniu run .
Testy świadome swoich ustawień
UWAGA: Nie jest to bardzo powszechny przypadek użycia. Jest udokumentowany pod kątem kompletności, ale zwykle nie jest potrzebny.
Niektóre implementacje programu uruchamiającego testy mogą wymagać informacji o ogólnej konfiguracji, aby działały poprawnie, na przykład niektórych metadanych dotyczących wywołania lub tego, który target_preparer był wcześniej uruchamiany itp.
Aby to osiągnąć, program uruchamiający testy może uzyskać dostęp do obiektu IConfiguration , którego jest częścią i w którym jest wykonywany. Więcej informacji można znaleźć w opisie obiektu konfiguracji .
W przypadku implementacji programu uruchamiającego testy należy zaimplementować IConfigurationReceiver , aby otrzymać obiekt IConfiguration .
Elastyczny biegacz testowy
Osoby uruchamiające testy mogą zapewnić elastyczny sposób przeprowadzania testów, jeśli mają nad nimi szczegółową kontrolę, na przykład program uruchamiający testy JUnit może indywidualnie uruchamiać każdy test jednostkowy.
Pozwala to większej uprzęży i infrastrukturze na wykorzystanie tej precyzyjnej kontroli, a użytkownikom na częściowe uruchamianie testera poprzez filtrowanie .
Obsługa filtrowania jest opisana w interfejsie ITestFilterReceiver , który pozwala na otrzymywanie zestawów filtrów include i exclude dla testów, które powinny lub nie powinny być uruchamiane.
Zgodnie z naszą konwencją test zostanie uruchomiony IFF, jeśli pasuje do jednego lub więcej filtrów uwzględniania ORAZ nie pasuje do żadnego z filtrów wykluczających. Jeśli nie podano żadnych filtrów uwzględniania, należy uruchomić wszystkie testy, o ile nie pasują do żadnego z filtrów wykluczania.
UWAGA: Zachęcamy uczestników testów do pisania w sposób, który obsługuje to filtrowanie, ponieważ zapewnia ogromną wartość dodaną w większej infrastrukturze. Rozumiemy jednak, że w niektórych przypadkach nie jest to możliwe.