Jak mogę użyć niestandardowego runnera podczas używania kategorii w Junit?

Question

Mam kilka testów JUnit, które rozszerzają moją podstawową klasę testową o nazwie BaseTest, która z kolei rozszerza Assert. Niektóre z moich testów mają adnotację @Category(SlowTests.class).

Moja klasa BaseTest jest opatrzona adnotacją o następującej treści: @RunWith(MyJUnitRunner.class).

Mam skonfigurować zadanie Gradle, który ma działać tylko SlowTests. Oto moje zadanie Gradle:

task integrationTests(type: Test) { 
    minHeapSize = "768m" 
    maxHeapSize = "1024m" 
    testLogging { 
     events "passed", "skipped", "failed" 
     outputs.upToDateWhen {false} 
    } 
    reports.junitXml.destination = "$buildDir/test-result" 
    useJUnit { 
     includeCategories 'testutils.SlowTests' 
    } 
} 

Po uruchomieniu zadania moje testy nie są wykonywane. Zauważyłem, że ten problem jest powiązany z niestandardowym biegaczem MyJUnitRunner na BaseTest. W jaki sposób mogę ustawić moją Gradle lub strukturę testową, aby móc używać niestandardowego runnera podczas korzystania z Suite.

Answer 1

Rozwiązanie tego problemu okazało się mniejsze i trudniejsze niż myślałem. Gradle używał mojego niestandardowego programu testowego i poprawnie wywoływał metodę filter. Jednak mój runner wczytuje wszystkie klasy testowe za pomocą własnego programu ładującego klasy dla ulepszeń Javaassist.

To doprowadziło do problemu, że adnotacja SlowTest została załadowana za pośrednictwem programu ładującego klasy Gradle, ale po przekazaniu do mojego niestandardowego programu uruchamiającego, uczestnik sprawdził, czy klasa została opatrzona adnotacją z tą adnotacją. Sprawdzanie to nigdy nie zostało rozwiązane poprawnie, ponieważ równość adnotacji SlowTest ładowana przez dwa różne moduły ładujące klasy była inna.

-

Odkąd już zrobione badania, będę po prostu zostawić to tutaj. Po kilku dniach kopania przez Gradle i (tajemnicze) źródła JUnit, oto co otrzymałem.

Gradle po prostu nie obsługuje żadnej zaawansowanej funkcjonalności JUnit z wyjątkiem kategoryzacji testów. Podczas tworzenia zadania Gradle z kategoriami uwzględnienia lub warunkami kategorii wykluczeń buduje się filtr kategorii. Jeśli nie wiesz, Filter jest tym, co JUnit przekazuje testerowi, aby zdecydować, czy test lub metoda testu powinna zostać odfiltrowana. Biegacz testowy musi wdrożyć interfejs Filterable.

JUnit jest dostarczany z wieloma biegaczami, Categories to tylko jeden z nich. Rozszerza rodzinę biegaczy testowych o nazwie Suite. Te biegacze oparte na pakietach są zaprojektowane do uruchamiania "zestawu" testów. Zestaw testów można zbudować za pomocą introspekcji opisów, definiując jednoznacznie testy w pakiecie lub dowolną inną metodę, która tworzy zestaw testów.

W przypadku biegacza Categories JUnit ma swój własny CategoryFilter, ale Gradle tego nie używa, używa własnego CategoryFilter. Oba zapewniają mniej więcej tę samą funkcjonalność i są filtrami JUnit, więc mogą być używane przez każdy pakiet, który implementuje Filterable.

Rzeczywista klasa w Gradle odpowiedzialna za przeprowadzenie testów JUnit nosi nazwę JUnitTestClassExecuter. Po przeanalizowaniu opcji wiersza poleceń, prosi JUnit o sprawdzenie, czy runner powinien zostać użyty do testu. Ta metoda jest wywoływana dla każdego testu, jak widać here.

Reszta to po prostu JUnit. Gradle właśnie utworzył niestandardowy RunNotifier do generowania standardowych plików XML reprezentujących wyniki testu.

Mam nadzieję, że ktoś znajdzie to przydatne i zaoszczędzi niezliczone godziny debugowania.

TLDR: Możesz użyć dowolnego biegacza w Gradle. Gradle nie ma żadnych szczegółów dotyczących biegaczy. To JUnit zdecydowało biegaczy. Jeśli chcesz wiedzieć, jaki runner zostanie użyty w teście, możesz go usunąć, dzwoniąc pod numer Request.aClass(testClass).getRunner(). Zrób to gdzieś w swojej bazie kodu i wypisz ją na konsoli. (Nie udało mi się dołączyć debuggera do Gradle.)