W celu uzyskania pełnego kodu należy wdrożyć testy hosta archiwum Java (JAR) zasięgu Twojego oprogramowania. Wykonaj instrukcje, aby utworzyć testy jednostek lokalnych. Pisanie małych testów jednostkowych sprawdzających konkretną funkcję i nic więcej.
Przykład
Ten plik Blueprint zawiera prosty przykład testu hosta JAR Hello World który należy skopiować i dostosować do swoich potrzeb: platform_testing/tests/example/jarhosttest/Android.bp
Odpowiada to faktycznemu kodowi testowemu, który znajduje się pod adresem: test_platformy/tests/example/jarhosttest/test/android/test/example/helloworld/HelloWorldTest.java
Dla wygody użytkowników zamieszczamy tutaj migawkę pliku projektu:
java_test_host {
name: "HelloWorldHostTest",
test_suites: ["general-tests"],
srcs: ["test/**/*.java"],
static_libs: [
"junit",
"mockito",
],
}
Deklaracja java_test_host
na początku wskazuje, że jest to plik JAR
test hosta. Przykład użycia:
frameworks/base/tools/powermodel/Android.bp
Ustawienia
Poniżej znajdziesz objaśnienia tych ustawień:
Ustawienie
name
jest wymagane, gdy typ modułujava_test_host
to (na początku bloku). To ustawienie nadaje nazwę usłudze , a wynikowy plik JAR będzie miał tę samą nazwę i sufiks.jar
. W w poniższym przykładzie testowy plik JAR ma nazwęHelloWorldHostTest.jar
. W to ustawienie określa też nazwę celu dla modułu, aby utworzyć test w narzędziumake [options] <HelloWorldHostTest>
i wszystkich zależnościach tego modułu.name: "HelloWorldHostTest",
Ustawienie
test_suites
ułatwia znalezienie testu na platformie handlowej Ekstraktor federacji. Można tu dodawać też inne zestawy testowe, np. CTS, aby można było udostępnić test hosta JAR.test_suites: ["general-tests"],
Ustawienie
static_libs
instruuje system kompilacji, aby uwzględniał zawartości nazwanych modułów do wynikowego pakietu APK bieżącego modułu. Oznacza to, że każdy moduł nazwany powinien wygenerować plik.jar
. Zawartość modułu służy do rozpoznawania odwołań do ścieżki klasy podczas czas kompilowania i uwzględniać w otrzymanym pliku APK.static_libs: [ "junit", ],