JUnit 4 vs TestNG - aktualizacja 2013-2014 [zamknięte]

88

JUnit 4 i TestNG były kiedyś porównywalne. Jakie są wady i zalety obu platform testowych?

ctekk
źródło
Jeśli patrzysz na porównanie funkcji, jest dobry artykuł autorstwa mkyong na jUnit 4 Vs testNG Jeśli chcesz odnieść się do porównania użytkowania. Jest fajny artykuł autorstwa Kapila Hope, który pomaga!
Anshu
71
Uważam, że pytania takie jak to są niezwykle pomocne w SO ... Chciałbym podziękować za podjęcie ryzyka i pogratulować zamknięcia go!
user1445967
Sposobem na przeciwstawienie się publiczności: D
ctekk,
2
Widząc to pytanie ponownie po tylu latach. Zabawne jest to, że czuję spisk! Moje pytanie było całkowicie skoncentrowane na różnych funkcjach, potem pojawiła się edycja "społeczności", która zredagowała moje pytanie do "za i przeciw", a następnie pytanie zostało zamknięte z powodu opinii. Lmao.
ctekk

Odpowiedzi:

29

Porównywałem dzisiaj TestNG i JUnit4, a główną zaletą, którą mogę wskazać z moim ograniczonym doświadczeniem w testowaniu frameworków, jest to, że TestNG ma bardziej elegancki sposób obsługi sparametryzowanych testów z koncepcją dostawcy danych.

O ile wiem, w JUnit4 musisz utworzyć oddzielną klasę testową dla każdego zestawu parametrów, z którymi chcesz testować (działał @RunWith(Parameterized.class)). Dzięki TestNG możesz mieć wielu dostawców danych w jednej klasie testowej, dzięki czemu możesz przechowywać wszystkie testy dla jednej klasy w jednej klasie testowej.

Jak dotąd jest to jedyna rzecz, którą mogę wskazać jako przewagę TestNG nad JUnit4.

Intellij IDEA zawiera wsparcie dla TestNG i JUnit po wyjęciu z pudełka. Jednak Eclipse obsługuje tylko JUnit po wyjęciu z pudełka i wymaga zainstalowania wtyczki TestNG, aby działała.

Jednak bardziej irytującym problemem, na który natknąłem się w TestNG, jest to, że twoje klasy testowe muszą zostać rozszerzone, PowerMockTestCasejeśli używasz PowerMock do mockowania zależności w swoich testach. Najwyraźniej istnieją sposoby na skonfigurowanie fabryki obiektów, o której musi wiedzieć Twoja platforma testowa podczas korzystania z PowerMock za pomocą specjalnej metody lub testng.xmldefinicji pakietu, ale w tej chwili wydaje się, że są one zepsute. Nie podoba mi się, gdy klasy testowe rozszerzają klasy struktury testowej, wydaje się to hakerskie.

Jeśli nie używasz PowerMocka, to oczywiście nie jest to problem, ale w sumie mam wrażenie, że JUnit4 jest lepiej obsługiwany.

JeroenHoek
źródło
5
Nie żeby istniały alternatywne implementacje testów parametryzowanych, na przykład code.google.com/p/junitparams. A jeśli nie lubisz żadnego z nich, możesz napisać własne - to właśnie lubię w rozszerzalności JUnit. ;)
Esko Luontola
17

Opierając się na moim doświadczeniu z obydwoma frameworkami, testng ma kilka wygodnych funkcji, których wdrożenie zespół JUnit odmawiał przez kilka lat. Z tego powodu wolę to od JUnit. Konwersja do testng jest łatwa, ponieważ w zasadzie obsługuje prawie wszystko w JUnit (jest nawet wtyczka konwertera do zaćmienia), konwersja z powrotem do JUnit nie jest tak świetna z powodu tych brakujących funkcji.

  • W testng @BeforeClassmetody nie są statyczne i są wykonywane przed uruchomieniem testów w tej klasie, a nie po załadowaniu klasy testowej (zachowanie JUnit). Miałem kiedyś projekt JUnit, w którym wszystkie testy bazy danych (kilkadziesiąt) inicjowały bazę danych na samym początku, co było dość idiotycznym zachowaniem. W społeczności JUnit toczyło się wiele debat za i przeciw. Istotą tego było to, że każda metoda testowa powinna mieć własne urządzenie testowe i dlatego nie powinieneś mieć metody w stylu beforeAll, która nie jest statyczna, ponieważ pozwoliłoby to podstępnie ustawić zmienną instancji raz, a następnie użyć jej we wszystkich testach. Prawidłowe, ale naprawdę denerwujące dla testów integracyjnych. TestNG daje użytkownikom wybór tutaj. Junit nie, z założenia, co jest denerwujące.

  • Dostawcy danych Testng są nieco bardziej elastyczni niż odpowiednik JUnit. Możesz określić dla każdego testu, która metoda dostawcy danych powinna zapewniać dane wejściowe, zamiast mieć jeden rozmiar dla wszystkich rozwiązań dla całej klasy, jak w JUnit. Możesz więc mieć dostawców danych przypadków pozytywnych i negatywnych do testów w jednej klasie. Bardzo miło mieć.

  • Możesz oznaczyć klasę @Testw testng, co oznacza: każda metoda publiczna jest testem. W Junit musisz skopiować / wkleić @Testkażdą metodę.

Irytujący jest sposób, w jaki hamcrest jest dołączany do JUnit oraz sposób, w jaki JUnit jest dołączany do testng. W Maven są alternatywne słoiki, które nie mają tego problemu.

Moim wielkim zmartwieniem w przypadku obu frameworków jest to, że oba wydają się przestać ewoluować. Wydania są coraz rzadsze i mają coraz mniej godnych uwagi cech. Wydaje się, że cały ruch BDD miał niewielki wpływ na przykład na obie ramy. Ponadto JUnit mógł po prostu przyjąć większość z tego, co wymieniłem powyżej. Nie ma dobrego technicznego powodu, dla którego JUnit nie może zaimplementować żadnej z tych rzeczy; ludzie stojący za JUnit po prostu decydują się nie wdrażać tych rzeczy. Oba projekty wydają się również nie mieć wizji przyszłych kierunków i wydają się być szczęśliwi, wykonując tylko drobne poprawki przez ostatnie kilka lat.

Jilles van Gurp
źródło
9

Szukałem dobrych powodów, aby zmienić TestNG na JUnit i znalazłem te slajdy Tomka Kaczanowskiego, które bardzo dobrze odpowiadają na to pytanie. Tomek jest autorem książki Practical Unit Testing, która wydaje się być bardzo szanowana przez programistów i testerów.

MajiK
źródło
1

Jeśli pracujesz nad projektem Java / Scala, a Gradle jest Twoim preferowanym narzędziem do budowania, pamiętaj, że ScalaTestframework musi tylko JUnitRunneruruchamiać testy scala. Innymi słowy, masz wybór:

  • Testy Java JUnit + Testy Scala uruchamiane z JUnitRunner => Lepsza integracja z Gradle
  • Java testNG testy + Scala Testy uruchamiane ze Scala Runner => Słaba integracja Gradle, ponieważ program uruchamiający testy Scala jest pojedynczym zadaniem zbiorczym z punktu widzenia Gradle.
Ivan Balashov
źródło
0

Możesz użyć Mockito jako frameworka do kpiny. Ładnie integruje się z TestNG. Nie musisz rozszerzać żadnej klasy, aby używać Mockito z TestNG. W ten sposób testowany kod jest mniej powiązany i jeśli z jakiegoś powodu potrzebujesz użyć innych frameworków do makietowania, jest to łatwe.

El Do
źródło
7
Ta odpowiedź jest po prostu zupełnie nieistotna na pytanie…
Adrian Shum,
11
@AdrianShum Myślę, że Konrad próbował skomentować punkt JeroenHoek dotyczący integracji PowerMock z TestNG, ponieważ wydaje się, że nie ma przywileju „komentowania”. Zakładam, że umieścił swój komentarz jako odpowiedź
Taoufik Mohdit
1
Ta odpowiedź nie rozumie, czym jest PowerMock. Nie jest zamiennikiem dla Mockito, ale uzupełnieniem, które pozwala Mockito na kpiny z pewnych rzeczy, których Mockito nie potrafi samodzielnie (metody statyczne, klasy końcowe).
stickfigure
0

W skrócie..

Jeśli Twój zakres jest ograniczony do drobnych, szczegółowych testów jednostkowych bez zależności między nimi, możesz użyć JUnit.

Jeśli Twój zakres wymaga testów funkcjonalnych, które mogą / nie wymagać zależności i udostępniania danych (parametrów) między testami, wybierz TestNG. Ponadto TestNG może przeprowadzać testy jednostkowe podobne do JUnit. Więc możesz mieć zestaw testów jednostkowych i zestaw testów funkcjonalnych.

nabster
źródło