Na tej stronie opisano, jak napisać nowego wykonawcę testów w Tradefed.
Tło
Jeśli chcesz dowiedzieć się więcej o miejscu testów w architekturze Tradefed, zapoznaj się z artykułem Struktura testu.
Nie jest to warunek wstępny do napisania nowego narzędzia do testowania. Narzędzie do testowania można napisać niezależnie.
Minimum: wdrożenie interfejsu
Minimalnym wymogiem, aby spełniać kryteria testu Tradefed, jest implementacja interfejsu IRemoteTest, a w szczególności metody run(TestInformation testInfo, ITestInvocationListener listener).
Ta metoda jest wywoływana przez narzędzie, gdy używasz narzędzia do testowania, podobnie jak w przypadku metody Runnable w języku Java.
Każda część tej metody jest uważana za część wykonania testu.
Raportowanie wyników z testów
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 narzędzia.
W przypadku raportowania uporządkowanych wyników testów testujący ma te właściwości:
- raportuje odpowiednią listę wszystkich przeprowadzonych testów, ich czas trwania oraz informacje o tym, czy każdy z nich zakończył 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 uruchomienia jako „ZALECANY” lub „NIEZALECANY” bez żadnych szczegółów dotyczących faktycznego wykonania.
Aby powiadomić mechanizm o bieżącym postępie wykonywania, możesz wywołać w słuchaczu te zdarzenia:
- testRunStarted: powiadamia o początku grupy powiązanych ze sobą przypadków testowych.
- testStarted: powiadamia o rozpoczęciu testu.
- 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 pójść dobrze lub niepójść 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 pozytywne, ale z błędnym kodem zakończenia (z dowolnych powodów, np. wyciek plików).
- testRunEnded: powiadamia o zakończeniu grupy przypadków testowych.
Za utrzymanie prawidłowej kolejności wywołań metod obsługi zdarzeń 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 zostać uruchomiony bez żadnych przypadków testowych.
Ta struktura zdarzeń jest inspirowana typową strukturą JUnit. Jest to celowe działanie, aby zachować podstawowe informacje, które deweloperzy zazwyczaj znają.
Raportowanie dzienników z testów
Jeśli piszesz własną klasę testu lub narzędzie do testowania Tradefed, zaimplementujesz interfejs IRemoteTest i uzyskasz obiekt ITestInvocationListener za pomocą metody run(). Z tego odbiorcy możesz korzystać, aby rejestrować pliki w taki 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 udostępnia interfejs API do interakcji z tym urządzeniem. - IBuildReceiver
pozwala testowi uzyskać obiekt
IBuildInfoutworzony 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, na przykład dodatkowych plików, oraz urządzeń testowych, które będą celem podczas wykonywania testu.
Testowanie na wielu urządzeniach
Narzędzie Tradefed obsługuje uruchamianie testów na wielu urządzeniach jednocześnie. Jest to przydatne podczas testowania komponentów, które wymagają interakcji zewnętrznej, takich jak parowanie telefonu i zegarka.
Aby napisać test runner, który może używać wielu urządzeń, musisz zaimplementować interfejs IMultiDeviceTest, który umożliwi otrzymanie mapy ITestDevice do 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 zrobić, 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.
Aby zaimplementować test runner, musisz zaimplementować interfejs IConfigurationReceiver, aby odbierać obiekt IConfiguration.
Elastyczny testujący
Uruchamianie testów może być elastyczne, jeśli mają one szczegółową 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ą test jest wykonywany, jeśli pasuje do co najmniej 1 filtru uwzględniającego i nie pasuje do żadnego filtra wykluczającego. 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.