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

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

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.

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.

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.

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.

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.

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.