Chcę wykonać metody testowe opatrzone adnotacjami @Test
w określonej kolejności.
Na przykład:
public class MyTest {
@Test public void test1(){}
@Test public void test2(){}
}
Chcę mieć pewność, że uruchomię się test1()
przed test2()
każdym uruchomieniem MyTest
, ale nie mogłem znaleźć adnotacji takiej jak @Test(order=xx)
.
Myślę, że jest to dość ważna funkcja dla JUnit, jeśli autor JUnit nie chce funkcji zamawiania , dlaczego?
java
unit-testing
junit
junit4
远 声 远 Shengyuan Lu
źródło
źródło
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
, zachować@Test
adnotacji dla wszystkich metod badawczych i ich nazwy alfabetycznie zależności od pożądanej kolejności wykonywania, npt1_firstTest()
,t2_secondTest()
itpOdpowiedzi:
Nie jestem pewien, czy istnieje czysty sposób, aby to zrobić za pomocą JUnit, o ile wiem, JUnit zakłada, że wszystkie testy można wykonać w dowolnej kolejności. Z FAQ:
Dlaczego tak jest Uważam, że uzależnienie kolejności testów jest praktyką, której autorzy nie chcą promować. Testy powinny być niezależne, nie powinny być łączone, a naruszenie tego sprawi, że będzie trudniej utrzymać, przerwie możliwość uruchamiania testów indywidualnie (oczywiście) itp.
Biorąc to pod uwagę, jeśli naprawdę chcesz iść w tym kierunku, rozważ użycie TestNG, ponieważ obsługuje on natywnie uruchamianie metod testowych w dowolnej dowolnej kolejności (a takie rzeczy, jak określenie, że metody zależą od grup metod). Cedric Beust wyjaśnia, jak to zrobić , wykonując testy w teście .
źródło
Jeśli pozbędziesz się istniejącej instancji Junit i pobierzesz JUnit 4.11 lub nowszy ze ścieżki kompilacji, następujący kod wykona metody testowe w kolejności ich nazw, posortowane w kolejności rosnącej:
źródło
@Inherited
i dlatego staje się nieskuteczna w mojejAbstractTestCase
klasie nadrzędnej.Jeśli zamówienie jest ważne, należy je złożyć samodzielnie.
W szczególności powinieneś wymienić niektóre lub wszystkie możliwe kombinacje zleceń do przetestowania, jeśli to konieczne.
Na przykład,
Lub pełny test wszystkich permutacji:
Tutaj
permute()
jest prosta funkcja, która iteruje wszystkie możliwe permuacje w zbiorze tablic.źródło
test2
uruchamia siętest1
ponownie . Junit może nadal działaćtest2
wcześniejtest1
. Prawdopodobnie nie jest to zamierzenie, które nie jest prawidłową odpowiedzią na pytanie.Migracja do TestNG wydaje się najlepszym sposobem, ale nie widzę tutaj jasnego rozwiązania dla jUnit. Oto najbardziej czytelne rozwiązanie / formatowanie , które znalazłem dla jUnit:
Dzięki temu metody stage2 są wywoływane po metodach stage1 i przed stage3.
źródło
0
prefiks, np.void stage01_prepareAndTest(){ }
Jest to jeden z głównych problemów, z którymi musiałem się zmierzyć, pracując nad Junit i wymyśliłem następujące rozwiązanie, które działa dobrze dla mnie:
utwórz również interfejs jak poniżej:
Załóżmy teraz, że masz klasę A, w której napisałeś kilka przypadków testowych, takich jak poniżej:
Wykonanie rozpocznie się od metody o nazwie „method ()”. Dzięki!
źródło
@RunWith(PowerMockRunner.class) @PowerMockRunnerDelegate(OrderedRunner.class)
JUnit obecnie zezwala na kolejność uruchamiania metod testowych przy użyciu adnotacji klas:
Domyślnie metody testowe są uruchamiane w kolejności alfabetycznej. Aby ustawić kolejność metod, możesz nazwać je w następujący sposób:
Przykłady można znaleźć tutaj .
źródło
(Dotychczas niepublikowana) zmiana https://github.com/junit-team/junit/pull/386 wprowadza
@SortMethodsWith
. https://github.com/junit-team/junit/pull/293 przynajmniej sprawiło, że kolejność była przewidywalna bez tego (w Javie 7 może być dość losowa).źródło
@FixMethodOrder
nie nazywa się to@SortMethodsWith
w 4.11Spójrz na raport JUnit. JUnit jest już zorganizowany według pakietów. Każdy pakiet ma (lub może mieć) klasy TestSuite, z których każda z kolei uruchamia wiele TestCases. Każda TestCase może mieć wiele metod testowych formularza
public void test*()
, z których każda faktycznie stanie się instancją klasy TestCase, do której należą. Każda metoda testowa (instancja TestCase) ma nazwę i kryteria zaliczenia / niepowodzenia.To, czego wymaga moje zarządzanie, to koncepcja poszczególnych elementów TestStep , z których każdy zgłasza własne kryteria zaliczenia / niepowodzenia. Niepowodzenie jakiegokolwiek kroku testowego nie może uniemożliwić wykonania kolejnych kroków testowych.
W przeszłości programiści testów na moim stanowisku organizowali klasy TestCase w pakiety odpowiadające częściom testowanego produktu, tworzyli klasę TestCase dla każdego testu i uczynili każdą metodę testową osobnym „krokiem” w teście, wraz z własnymi kryteriami pozytywnego / negatywnego wyjścia JUnit. Każda TestCase jest samodzielnym „testem”, ale poszczególne metody lub „kroki” testowe w ramach TestCase muszą występować w określonej kolejności.
Metody TestCase były etapami TestCase, a projektanci testów otrzymali osobne kryterium zaliczenia / niepowodzenia na krok testu. Teraz kroki testowe są pomieszane, a testy (oczywiście) kończą się niepowodzeniem.
Na przykład:
Każda metoda testowa potwierdza i zgłasza swoje własne kryteria pozytywnego / negatywnego wyniku. Zebranie tego w „jedną wielką metodę testową” w celu zamówienia traci szczegółowość kryteriów pozytywnych / negatywnych każdego „kroku” w raporcie podsumowującym JUnit. ... i to denerwuje moich menedżerów. Obecnie domagają się innej alternatywy.
Czy ktokolwiek może wyjaśnić, w jaki sposób JUnit z kodowaniem kodowanym metodą testową obsługiwałby osobne kryteria zaliczenia / niepowodzenia dla każdego kolejnego etapu testu, jak pokazano powyżej i jest wymagane przez moje kierownictwo?
Niezależnie od dokumentacji uważam to za poważną regresję w środowisku JUnit, która utrudnia życie wielu programistom testów.
źródło
Aktualizacja JUnit 5 (i moja opinia)
Domyślnie biblioteki testów jednostkowych nie próbują wykonywać testów w kolejności występującej w pliku źródłowym.
JUnit 5 jako JUnit 4 działają w ten sposób. Dlaczego ? Ponieważ jeśli kolejność ma znaczenie, oznacza to, że niektóre testy są między nimi połączone i jest to niepożądane w przypadku testów jednostkowych .
Tak więc
@Nested
funkcja wprowadzona przez JUnit 5 stosuje to samo domyślne podejście.Jednak w przypadku testów integracyjnych kolejność metody testowej może mieć znaczenie, ponieważ metoda testowa może zmienić stan aplikacji w sposób oczekiwany przez inną metodę testową. Na przykład, gdy piszesz test integracji przetwarzania transakcji w sklepie internetowym, pierwszą metodą testową do wykonania jest rejestracja klienta, druga to dodawanie produktów do koszyka, a ostatnia to kasy. Jeśli testujący nie przestrzega tej kolejności, scenariusz testowy jest wadliwy i zakończy się niepowodzeniem.
Tak więc w JUnit 5 (od wersji 5.4) masz taką samą możliwość ustawienia kolejności wykonywania poprzez oznaczenie klasy testowej za pomocą
@TestMethodOrder(OrderAnnotation.class)
i poprzez określenie kolejności@Order(numericOrderValue)
dla metod, dla których kolejność ma znaczenie.Na przykład :
Wynik :
Nawiasem mówiąc, określenie
@TestMethodOrder(OrderAnnotation.class)
wygląda jak niepotrzebne (przynajmniej w wersji 5.4.0, którą testowałem).Uwaga dodatkowa
Na pytanie: czy JUnit 5 jest najlepszym wyborem do pisania testów integracyjnych? Nie sądzę, że powinno to być pierwsze narzędzie do rozważenia (Ogórek i spółka mogą często przynosić bardziej szczegółowe wartości i funkcje do testów integracji), ale w niektórych przypadkach testów integracji wystarczy środowisko JUnit. To dobra wiadomość, że ta funkcja istnieje.
źródło
Nie jestem pewien, czy zgadzam się. Jeśli chcę przetestować „Przesyłanie pliku”, a następnie przetestować „Dane wstawione przez przesyłanie pliku”, dlaczego nie chcę, aby były one od siebie niezależne? Całkowicie uzasadnione, myślę, że mogę je uruchomić osobno, zamiast mieć oba w przypadku testu Goliata.
źródło
To, czego chcesz, jest całkowicie uzasadnione, gdy testy są uruchamiane jako pakiet.
Niestety nie ma czasu na podanie kompletnego rozwiązania, ale spójrz na klasę:
Pozwala to wywoływać przypadki testowe (z dowolnej klasy testów) w określonej kolejności.
Można ich użyć do tworzenia testów funkcjonalnych, integracyjnych lub systemowych.
To pozostawia testy jednostkowe bez określonej kolejności (zgodnie z zaleceniami), niezależnie od tego, czy przeprowadzasz je w ten sposób, czy nie, a następnie ponownie wykorzystujesz testy jako część większego obrazu.
Ponownie używamy / dziedziczymy ten sam kod do testów jednostkowych, integracyjnych i systemowych, czasem na podstawie danych, czasem na podstawie zatwierdzeń, a czasem jako pakiet.
źródło
Zobacz moje rozwiązanie tutaj: „Junit and java 7.”
W tym artykule opisuję, jak uruchamiać testy junit w kolejności - „tak jak w kodzie źródłowym”. Testy zostaną uruchomione w kolejności, w jakiej metody testowe pojawią się w pliku klasy.
http://intellijava.blogspot.com/2012/05/junit-and-java-7.html
Ale jak powiedział Pascal Thivent, nie jest to dobra praktyka.
źródło
W JUnit 5.4 możesz określić kolejność:
po prostu musisz adnotować swoją klasę
https://junit.org/junit5/docs/current/user-guide/#writing-tests-test-execution-order
używam tego w moim projekcie i działa bardzo dobrze!
źródło
Przeczytałem kilka odpowiedzi i zgadzam się, że nie jest to najlepsza praktyka, ale najprostszym sposobem na zamówienie testów - a domyślnym sposobem, w jaki JUnit uruchamia testy, jest alfabetycznie rosnąca nazwa.
Więc nazwij swoje testy w kolejności alfabetycznej, którą chcesz. Pamiętaj też, że nazwa testu musi zaczynać się od słowa test. Uważaj na liczby
test12 uruchomi się przed test2
więc:
testA_MyFirstTest testC_ThirdTest testB_ATestThatRunsSecond
źródło
Sprawdź to: https://github.com/TransparentMarket/junit . Uruchamia test w kolejności, w jakiej zostały określone (zdefiniowane w skompilowanym pliku klasy). Ponadto zawiera pakiet AllTests do uruchamiania testów zdefiniowanych przez pakiet podrzędny. Korzystając z implementacji AllTests, można rozszerzyć to rozwiązanie również o filtrowanie właściwości (kiedyś używaliśmy adnotacji @Fast, ale nie zostały one jeszcze opublikowane).
źródło
Oto rozszerzenie JUnit, które może zapewnić pożądane zachowanie: https://github.com/aafuks/aaf-junit
Wiem, że jest to sprzeczne z autorami filozofii JUnit, ale podczas korzystania z JUnit w środowiskach, które nie są rygorystycznymi testami jednostkowymi (jak praktykowane w Javie), może to być bardzo pomocne.
źródło
Skończyłem tutaj, myśląc, że moje testy nie zostały przeprowadzone w porządku, ale prawda jest taka, że bałagan był w moich asynchronicznych zadaniach. Podczas pracy z współbieżnością należy również przeprowadzać kontrole współbieżności między testami. W moim przypadku zadania i testy mają wspólny semafor, więc następne testy są zawieszane, dopóki uruchomione zadanie nie zwolni blokady.
Wiem, że nie jest to w pełni związane z tym pytaniem, ale może pomóc w rozwiązaniu właściwego problemu
źródło
możesz użyć jednego z następujących kodów:
źródło