Piszę testy jednostkowe i chcę używać JUnitParamsRunner
i MockitoJUnitRunner
dla jednej klasy testowej.
Niestety nie działa:
@RunWith(MockitoJUnitRunner.class)
@RunWith(JUnitParamsRunner.class)
public class DatabaseModelTest {
// some tests
}
Czy istnieje sposób na użycie obu, Mockito i JUnitParams w jednej klasie testowej?
java
unit-testing
junit
Hans-Helge
źródło
źródło
Odpowiedzi:
Nie możesz tego zrobić, ponieważ zgodnie ze specyfikacją nie możesz umieścić tej samej adnotacji dwa razy na tym samym elemencie z adnotacją.
Więc jakie jest rozwiązanie? Rozwiązaniem jest postawienie tylko jednego
@RunWith()
z biegaczem, bez którego nie można się obejść i zastąpienie drugiego czymś innym. W twoim przypadku myślę, że usunieszMockitoJUnitRunner
i zrobisz programowo to, co robi.Właściwie jedyne, co robi, to działa:
na początku przypadku testowego. Zatem najprostszym rozwiązaniem jest umieszczenie tego kodu w
setUp()
metodzie:Nie jestem pewien, ale prawdopodobnie powinieneś unikać wielokrotnego wywoływania tej metody za pomocą flagi:
Jednak lepsze rozwiązanie wielokrotnego użytku można wdrożyć zgodnie z regułami JUnt.
Teraz po prostu dodaj następujący wiersz do swojej klasy testowej:
i możesz uruchomić ten przypadek testowy z dowolnym biegaczem.
źródło
mockInitialized
jest zły. Chcesz mieć świeżą próbę na każdy test.Począwszy od JUnit 4.7 i Mockito 1.10.17, ta funkcja jest wbudowana; jest
org.mockito.junit.MockitoRule
klasa. Możesz go po prostu zaimportować i dodać liniędo klasy testowej.
źródło
@Rule public MockitoJUnitRule mockito = new MockitoJUnitRule(this);
MockitoAnnotations.initMocks(this)
bardzo wolno tworzy kpiny. Najbardziej wydajnym sposobem jest użycie @Runwith (MockitoJunitRunner.class)To rozwiązanie działa dla każdego możliwego biegacza, nie tylko ten przykład mockito. Na przykład; na wiosnę po prostu zmień klasy biegaczy i dodaj niezbędne adnotacje.
DatabaseModelTest
będzie prowadzony przez JUnit.TestMockitoJUnitRunner
zależy od tego (zgodnie z logiką) i zostanie uruchomione wewnątrz metody main w@Test
metodzie podczas wywołaniaJUnitCore.runClasses(TestMockitoJUnitRunner.class)
. Ta metoda zapewnia, że główny profil jest uruchamiany poprawnie przedstatic class TestMockitoJUnitRunner
pomocniczego, skutecznie implementując wiele zagnieżdżonych@RunWith
adnotacji z zależnymi klasami testowymi.Również na https://bekce.github.io/junit-multiple-runwith-dependent-tests
źródło
JUnitCore.runClasses()
bez sprawdzenia wyniku, ryzykujesz zamaskowanie błędów z testu wewnętrznego.assert(JUnitCore.runClasses(TestMockitoJUnitRunner.class).wasSuccessful());
przynajmniej zgłosi błądOd wydania PowerMock 1.6 możesz to zrobić równie łatwo jak
Wyjaśniono tutaj https://blog.jayway.com/2014/11/29/using-another-junit-runner-with-powermock/
źródło
W moim przypadku próbowałem Kpić z jakiejś metody w wiosennej fasoli i
nie działa. Zamiast tego musisz zdefiniować ten bean do konstruowania przy użyciu metody mock w pliku xml, jak poniżej.
i dodaj tę fasolę z autowiredem w klasie testowej, jak naśladowanie.
źródło
sprawdź ten link https://bekce.github.io/junit-multiple-runwith-dependent-tests/ stosując to podejście połączyłem @RunWith (Parameterized.class) - biegacz zewnętrzny - z @RunWith (MockitoJUnitRunner.class) - biegacz wewnętrzny. Jedyną poprawką, jaką musiałem dodać, było uczynienie moich zmiennych składowych w zewnętrznej klasie / runner statyczne, aby były dostępne dla wewnętrznej / zagnieżdżonej runner / klasy. mam szczęście i ciesz się.
źródło
Chciałem uruchomić SWTBotJunit4ClassRunner i org.junit.runners.Parametryzowane w tym samym czasie, mam testy parametryczne i chcę zrzuty ekranu, gdy test SWT się nie powiedzie (funkcję zrzutu ekranu zapewnia SWTBotJunit4ClassRunner ). Odpowiedź @ bekce jest świetna i najpierw chciałem iść tą drogą, ale albo było dziwaczne, gdy przechodziło przez argumenty. Lub zrobienie parametryzacji w podklasie i utrata informacji, jakie dokładnie testy przeszły / nie powiodły się i mają tylko ostatni zrzut ekranu (ponieważ nazwy zrzutów ekranu otrzymują nazwę z samego testu). Tak czy inaczej było trochę niechlujnie.
W moim przypadku SWTBotJunit4ClassRunner jest dość prosty, więc sklonowałem kod źródłowy klasy, nadałem mu własną nazwę ParametrizedScreenshotRunner i tam, gdzie oryginał rozszerzał TestRunner , moja klasa rozszerzyła parametr Parameterized klasę więc w zasadzie mogę użyć własnego runnera zamiast dwóch poprzednich. Podsumowując, mój własny runner rozszerza się na Sparametryzowany biegacz, jednocześnie implementując funkcję zrzutu ekranu, teraz mój test używa tego „hybrydowego” biegacza i wszystkie testy działają zgodnie z oczekiwaniami od razu (nie ma potrzeby niczego zmieniać w testach).
Tak to wygląda (ze względu na zwięzłość usunąłem wszystkie komentarze z aukcji):
źródło
Możesz też spróbować tego:
źródło