Na tej stronie opisujemy, jak napisać nowy program do uruchamiania testów w Tradefed.
Tło
Jeśli chcesz dowiedzieć się więcej o miejscu narzędzi do uruchamiania testów w architekturze Tradefed, zapoznaj się z sekcją Struktura narzędzia do uruchamiania testów.
Nie jest to warunek wstępny do napisania nowego narzędzia do uruchamiania testów. Można je pisać niezależnie.
Minimum: zaimplementuj interfejs
Aby kwalifikować się jako moduł uruchamiający testy Tradefed, musisz zaimplementować interfejs IRemoteTest, a w szczególności metodę run(TestInformation testInfo, ITestInvocationListener listener).
Ta metoda jest wywoływana przez platformę podczas korzystania z uruchamiacza testów, podobnie jak interfejs Runnable w Javie.
Każda część tej metody jest uznawana za część wykonania narzędzia do uruchamiania testów.
Raportowanie wyników z programu do uruchamiania testów
Metoda run w interfejsie podstawowym daje dostęp do obiektu detektora typu ITestInvocationListener. Ten obiekt jest kluczem do raportowania wyników strukturalnych z programu testującego do platformy.
Dzięki raportowaniu wyników strukturalnych narzędzie do uruchamiania testów ma te właściwości:
- Raport powinien zawierać listę wszystkich przeprowadzonych testów, czas ich trwania oraz informację, czy każdy z nich zakończył się sukcesem, niepowodzeniem czy w inny sposób.
- W stosownych przypadkach raportuj dane związane z testami, np. dane dotyczące czasu instalacji.
- Pasuje do większości narzędzi infrastrukturalnych, np. do wyświetlania wyników i danych itp.
- Zwykle łatwiej jest debugować, ponieważ śledzenie wykonania jest bardziej szczegółowe.
Raportowanie wyników strukturalnych jest jednak opcjonalne. Program uruchamiający testy może po prostu ocenić stan całego przebiegu jako ZALICZONY lub NIEZALICZONY bez podawania szczegółów dotyczących rzeczywistego wykonania.
W przypadku słuchacza można wywołać te zdarzenia, aby powiadomić platformę o bieżącym postępie wykonywania:
- testRunStarted: powiadamia o początku grupy powiązanych ze sobą przypadków testowych.
- testStarted: powiadamia o rozpoczęciu testu.
- testFailed/testIgnored: powiadamia o zmianie stanu testu w trakcie realizacji. Przypadek testowy bez zmiany stanu jest uznawany za zaliczony.
- testEnded: powiadamia o zakończeniu elementu testowania.
- testRunFailed: powiadamia, że ogólny stan wykonania grupy przypadków testowych to niepowodzenie. Wykonanie testu może zakończyć się sukcesem lub niepowodzeniem niezależnie od wyników przypadków testowych, w zależności od tego, czego oczekiwano od wykonania. Na przykład plik binarny uruchamiający kilka przypadków testowych może zgłosić wszystkie przypadki testowe jako zdane, ale z kodem zakończenia błędu (z dowolnych powodów: wyciek plików itp.).
- testRunEnded: powiadamia o zakończeniu grupy przypadków testowych.
Utrzymanie i zapewnienie prawidłowej kolejności wywołań zwrotnych jest obowiązkiem osoby wdrażającej narzędzie do uruchamiania testów. Należy na przykład zadbać o to, aby w przypadku wyjątku wywoływana była funkcja testRunEnded, używając klauzuli finally.
Wywołania zwrotne przypadków testowych (testStarted, testEnded itp.) są opcjonalne. Wykonanie testu może nastąpić bez żadnych przypadków testowych.
Możesz zauważyć, że ta struktura zdarzeń jest inspirowana typową strukturą JUnit. Ma to na celu zachowanie prostoty, aby deweloperzy mieli podstawową wiedzę na ten temat.
Raportowanie logów z programu do uruchamiania testów
Jeśli piszesz własną klasę testową lub moduł uruchamiający Tradefed, zaimplementujesz interfejs IRemoteTest i uzyskasz ITestInvocationListener za pomocą metody run(). Ten odbiornik może służyć do rejestrowania plików w ten sposób:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Testowanie na urządzeniu
Powyższy interfejs minimalny umożliwia przeprowadzanie bardzo prostych testów, które są odizolowane i nie wymagają żadnych konkretnych zasobów, np. testów jednostkowych Java.
Osoby piszące testy, które chcą przejść do następnego etapu testowania urządzeń, będą potrzebować tych interfejsów:
- IDeviceTest
umożliwia odbieranie obiektu
ITestDevice, który reprezentuje testowane urządzenie i udostępnia interfejs API do interakcji z nim. - Interfejs IBuildReceiver umożliwia testowi uzyskanie obiektu
IBuildInfoutworzonego na etapie dostawcy kompilacji, który zawiera wszystkie informacje i artefakty związane z konfiguracją testu.
Programy do uruchamiania testów zwykle korzystają z tych interfejsów, aby uzyskać artefakty związane z wykonaniem, np. dodatkowe pliki, oraz urządzenie poddawane testom, które będzie celem podczas wykonywania testu.
Testowanie na wielu urządzeniach
Tradefed obsługuje przeprowadzanie testów na wielu urządzeniach jednocześnie. Jest to przydatne podczas testowania komponentów, które wymagają interakcji zewnętrznej, np. parowania telefonu i zegarka.
Aby napisać program testowy, który może używać wielu urządzeń, musisz zaimplementować interfejs IMultiDeviceTest, który umożliwia otrzymywanie mapy ITestDevice do IBuildInfo zawierającej pełną listę reprezentacji urządzeń i powiązanych z nimi informacji o kompilacji.
Metoda ustawiająca z interfejsu będzie zawsze wywoływana przed metodą run, więc można założyć, że struktura będzie dostępna, gdy zostanie wywołana metoda run.
Testy uwzględniające konfigurację
Niektóre implementacje narzędzia do uruchamiania testów mogą wymagać informacji o ogólnej konfiguracji, aby działać prawidłowo, np. metadanych dotyczących wywołania lub informacji o tym, które target_preparer zostały uruchomione wcześniej 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 znajdziesz w opisie obiektu konfiguracji.
W przypadku implementacji narzędzia do uruchamiania testów musisz zaimplementować interfejs IConfigurationReceiver, aby odbierać obiekt IConfiguration.
Elastyczny uruchamiający testy
Programy uruchamiające testy mogą zapewniać elastyczny sposób przeprowadzania testów, jeśli mają nad nimi szczegółową kontrolę. Na przykład program uruchamiający testy JUnit może uruchamiać każdy test jednostkowy osobno.
Dzięki temu większa wiązka i infrastruktura mogą wykorzystywać tę precyzyjną kontrolę, a użytkownicy mogą częściowo uruchamiać narzędzie do testowania za pomocą filtrowania.
Obsługa filtrowania jest opisana w interfejsie ITestFilterReceiver, który umożliwia odbieranie zestawów filtrów include i exclude dla testów, które powinny lub nie powinny być uruchamiane.
Zgodnie z naszą konwencją test zostanie przeprowadzony TYLKO WTEDY, GDY pasuje do co najmniej jednego filtra uwzględniania ORAZ nie pasuje do żadnego filtra wykluczania. Jeśli nie podano filtrów uwzględniania, należy uruchomić wszystkie testy, które nie pasują do żadnego z filtrów wykluczania.