JUnit vs TestNG [zamknięte]

W pracy nadal używamy JUnit 3 do przeprowadzania naszych testów. Zastanawialiśmy się nad przejściem na JUnit 4 w celu pisania nowych testów, ale od jakiegoś czasu obserwuję TestNG. Jakie doświadczenia mieliście wszyscy z JUnit 4 lub TestNG, a które wydaje się działać lepiej w przypadku bardzo dużej liczby testów? Elastyczność w pisaniu testów jest również dla nas ważna, ponieważ nasze testy funkcjonalne obejmują szeroki aspekt i muszą być napisane na wiele sposobów, aby uzyskać wyniki.

Stare testy nie zostaną ponownie napisane, ponieważ dobrze wykonują swoją pracę. To, co chciałbym zobaczyć w nowych testach, to elastyczność w sposobie pisania testu, naturalne asercje, grupowanie i łatwo dystrybuowane wykonania testów.

Użyłem obu, ale muszę zgodzić się z Justinem Standardem, że tak naprawdę nie powinieneś rozważać przepisywania istniejących testów do żadnego nowego formatu. Niezależnie od decyzji uruchomienie obu jest dość trywialne. TestNG stara się być znacznie bardziej konfigurowalny niż JUnit, ale ostatecznie oba działają równie dobrze.

TestNG ma fajną funkcję, w której możesz oznaczyć testy jako określoną grupę, a następnie łatwo uruchomić wszystkie testy z określonej grupy lub wykluczyć testy z określonej grupy. W ten sposób możesz oznaczyć testy, które działają wolno, jak w grupie „wolno”, a następnie zignorować je, jeśli chcesz uzyskać szybkie wyniki. Sugestią z ich dokumentacji jest oznaczenie pewnego podzbioru jako testów „checkin”, które powinny być uruchamiane za każdym razem, gdy sprawdzasz nowe pliki. Nigdy nie widziałem takiej funkcji w JUnit, ale z drugiej strony, jeśli jej nie masz, nie NAPRAWDĘ za tym tęsknię.

Mimo wszystkich twierdzeń o wysokiej konfiguracji, kilka tygodni temu natknąłem się na przypadek narożny, w którym nie mogłem zrobić tego, co chciałem ... Chciałbym pamiętać, co to jest, ale chciałem o tym wspomnieć więc wiesz, że nie jest doskonały.

Największą zaletą TestNG są adnotacje ... które JUnit i tak dodał w wersji 4.

Po pierwsze, powiedziałbym, nie przepisuj wszystkich swoich testów tylko po to, by pasowały do ​​najnowszej mody. Junit3 działa doskonale, a wprowadzenie adnotacji w 4 nie kupuje zbyt wiele (moim zdaniem). O wiele ważniejsze jest, abyście napisali testy, a wygląda na to, że to robicie.

Używaj tego, co wydaje się najbardziej naturalne i pomaga w wykonywaniu pracy.

Nie mogę komentować TestNG b / c Nie używałem go. Ale poleciłbym unitils , świetne opakowanie dla JUnit / TestNG / DBUnit / EasyMock, niezależnie od wybranej trasy. (Obsługuje wszystkie wymienione powyżej smaki)

Największe karty losowania TestNG obejmują dla mnie wsparcie grup testowych, a co ważniejsze - zależności grup testowych (oznaczenie testu jako zależnego od grupy powoduje, że testy po prostu pomijają uruchamianie, gdy grupa zależna zawodzi).

Inne duże karty do losowania TestNG obejmują dla mnie parametry testowe, dostawców danych, transformatory adnotacji, a przede wszystkim - dynamiczną i elastyczną społeczność użytkowników.

Chociaż na pierwszy rzut oka można by pomyśleć, że nie wszystkie powyższe funkcje TestNG mogą być niepotrzebne, gdy zaczniesz rozumieć elastyczność, jaką wnoszą do twoich testów, będziesz się zastanawiać, jak poradziłeś sobie z JUnit.

(zastrzeżenie - w ogóle nie korzystałem z JUnit 4.x, więc nie mogę tak naprawdę komentować postępów lub nowych funkcji).

Mniej więcej rok temu mieliśmy ten sam problem. Spędziłem trochę czasu zastanawiając się, który ruch był lepszy i ostatecznie zdaliśmy sobie sprawę, że TestNG nie ma „zabójczych funkcji”. Jest fajny i ma pewne funkcje, których JUnit 4 nie ma, ale ich nie potrzebujemy.
Nie chcieliśmy, aby ludzie czuli się nieswojo pisząc testy podczas poznawania TestNG, ponieważ chcieliśmy, aby pisali wiele testów.
Ponadto JUnit jest de facto standardem w świecie Java. Nie ma przyzwoitego narzędzia, które nie obsługuje go z pudełka, możesz znaleźć wiele pomocy w sieci i dodali wiele nowych funkcji w ciągu ostatniego roku, co pokazuje, że żyje.

Zdecydowaliśmy się pozostać przy JUnit i nigdy nie oglądaliśmy się za siebie.

Pozdrawiam wszystkie powyższe. Inne rzeczy, które osobiście uważam za bardziej lubiane w TestNG, to:

1. Plik @BeforeClassDla TestNG odbywa się po utworzeniu klasy, więc nie są ograniczone tylko jest w stanie wywołać metody statyczne swojej klasie w nim.

2. Testy równoległe i parametryzowane, może po prostu nie mam dość życia ... ale po prostu dostaję kopa pisząc jeden zestaw testów Selenium, akceptując nazwę sterownika jako parametr. Następnie zdefiniuj 3 równoległe grupy testowe, po 1 dla kierowców IE, FF i Chrome i oglądaj wyścig! Pierwotnie zrobiłem 4, ale zbyt wiele stron, nad którymi pracowałem, psuje HtmlUnitsterownik z tego czy innego powodu.

Tak, prawdopodobnie muszę znaleźć to życie. ;)

Chciałem podzielić się tym, którego dzisiaj spotkałem. Odkryłem, że wbudowany sparametryzowany runner jest dość prymitywny w Junit4 w porównaniu do TestNG (wiem, że każdy framework ma swoje mocne strony, ale nadal). Adnotacja Junit4 @parameters jest ograniczona do jednego zestawu parametrów. Napotkałem ten problem podczas testowania prawidłowego i nieprawidłowego zachowania funkcjonalności w tej samej klasie testowej. Tak więc pierwsza publiczna, statyczna metoda z adnotacjami, którą znajdzie, zostanie użyta, ale może znaleźć je w dowolnej kolejności. To powoduje, że niepotrzebnie piszemy różne klasy. Jednak TestNG zapewnia czysty sposób dostarczania różnych rodzajów dostawców danych dla każdej metody. Możemy więc przetestować tę samą jednostkę kodu w prawidłowy i niepoprawny sposób w tej samej klasie testowej, oddzielając prawidłowe / nieprawidłowe dane. Pójdę z TestNG.

Kolejną zaletą TestNG jest obsługa testów równoległych. Myślę, że w naszej erze wielordzeniowych jest to ważne.

Użyłem też obu frameworków. Ale ja używam hamcrest do twierdzeń. Hamcrest pozwala łatwo napisać własną metodę asertywności. Więc zamiast

assertEquals(operation.getStatus(), Operation.Status.Active);

Możesz pisać

assertThat(operation, isActive());

Daje to możliwość wykorzystania w testach wyższego poziomu abstrakcji. A to sprawia, że ​​testy są solidniejsze.

JUnit 4 Vs TestNG - Porównanie na stronie mkyong.com (aktualizacja 2013).

Wniosek: Sugeruję użycie TestNG jako podstawowej struktury testów jednostkowych dla projektu Java, ponieważ TestNG jest bardziej zaawansowany w testowaniu parametryzacji, testowaniu zależności i testowaniu pakietów (koncepcja grupowania).

TestNG jest przeznaczony do testów funkcjonalnych, wysokopoziomowych i złożonych testów integracyjnych. Jego elastyczność jest szczególnie przydatna w przypadku dużych zestawów testów.

Ponadto TestNG obejmuje również całą podstawową funkcjonalność JUnit4 . Po prostu nie ma już powodu, aby używać JUnit.

Krótko mówiąc, TestNG = JUnit + dużo więcej. Więc po co debatować? idź i weź TestNG :-)

Bardziej szczegółowe porównanie można znaleźć tutaj .

Kilka dodatków do odpowiedzi Mike'a Stone'a:

1) Najczęściej używam grup TestNG, gdy chcę uruchomić pojedynczą metodę testową w zestawie testów. Po prostu dodaję ten test do grupy „phil”, a następnie uruchamiam tę grupę. Kiedy używałem JUnit 3, komentowałem wpisy dla wszystkich metod oprócz tej, którą chciałem uruchomić w metodzie „zestawu”, ale często zapominałem o ich odkomentowaniu przed zameldowaniem. Z grupami nie mam już tego problemu.

2) W zależności od złożoności testów migracja testów z JUnit3 do TestNG może odbywać się w pewnym stopniu automatycznie za pomocą seda i tworzenia klasy bazowej w celu zastąpienia TestCase, która statycznie importuje wszystkie metody asercji TestNG.

Mam informacje o mojej migracji z JUnit do TestNG tutaj i tutaj .

Dlaczego używamy TestNG zamiast JUnit?

1. Deklaracja @BeforeClassi @AfterClassmetoda musi być statyczna w JUnit, podczas gdy w TestNG jest większa elastyczność w deklaracji metody, nie ma tych ograniczeń.

2. W TestNG możemy parametryzować testy na 2 sposoby . Adnotacja @Parameter lub @DataProvider.

   i) @Parameter dla prostych przypadków, w których wymagane jest mapowanie wartości klucza. (dane są dostarczane w pliku xml)

   ii) @DataProvider dla złożonych przypadków. Korzystając z dwuwymiarowej tablicy, może dostarczać dane.

3. W TestNG, ponieważ metoda @DataProvider nie musi być statyczna, możemy użyć wielu metod dostawcy danych w tej samej klasie testowej.

4. Testowanie zależności: w TestNG, jeśli początkowy test zakończy się niepowodzeniem, wszystkie kolejne testy zależne zostaną pominięte, a nie oznaczone jako zakończone niepowodzeniem. Ale JUnit oznaczył, że zawiodło.

5. Grupowanie: pojedyncze testy mogą należeć do wielu grup, a następnie być uruchamiane w różnych kontekstach (np. Wolne lub szybkie testy). Podobna funkcja istnieje w kategoriach JUnit, ale brakuje adnotacji @BeforeGroups / @AfterGroups TestNG, które umożliwiają zainicjowanie testu / zerwanie go.

6. Równoległość: jeśli chcesz uruchomić ten sam test równolegle na wielu wątkach, TestNG oferuje prostą w użyciu adnotację, podczas gdy JUnit nie oferuje prostego sposobu na zrobienie tego po wyjęciu z pudełka.

7. TestNG @DataProvider może również obsługiwać XML do przesyłania danych, plików CSV, a nawet zwykłych plików tekstowych.

8. TestNG umożliwia deklarowanie zależności między testami i pomijanie ich, jeśli test zależności nie przeszedł.

@Test (dependsOnMethods = {"dependOnSomething"})

Ta funkcja nie istnieje w JUnit

9. Raportowanie:

Raporty TestNG są generowane domyślnie w folderze test-output, który zawiera raporty HTML ze wszystkimi danymi testowymi, przeszły / nieudany / pominięty, jak długo działały, które dane wejściowe były używane i pełne dzienniki testów. Ponadto eksportuje wszystko do pliku XML, którego można użyć do skonstruowania własnego szablonu raportu.

Na froncie JUnit wszystkie te dane są również dostępne za pośrednictwem XML, ale nie ma raportu po wyjęciu z pudełka i musisz polegać na wtyczkach.

Link do zasobów:

1. Szybkie porównanie JUnit vs TestNG
2. JUnit a TestNG: Który framework testowy wybrać?

Dobra różnica jest podana w tym samouczku obok siebie: TestNG Vs JUnit: Jaka jest różnica?

Twoje pytanie wydaje mi się dwojakie. Z jednej strony chciałbyś porównać dwa frameworki testowe, z drugiej strony chciałbyś łatwo implementować testy, mieć naturalne asercje itp.

Ok, po pierwsze, JUnit grał w nadrabianie zaległości z TestNG pod względem funkcjonalności, częściowo wypełnili lukę w wersji 4, ale moim zdaniem nie wystarczająco dobrze. Rzeczy takie jak adnotacje i dostawcy danych są nadal znacznie lepsze w TestNG. Są również bardziej elastyczne pod względem wykonywania testów, ponieważ TestNG ma zależności, grupowanie i porządkowanie testów.

JUnit nadal wymaga, aby pewne metody przed / po były statyczne, co ogranicza to, co możesz zrobić przed uruchomieniem testów, TestNG nigdy nie ma tego problemu.

TBH, głównie różnice między tymi dwoma frameworkami nie mają większego znaczenia, chyba że skupisz się na testowaniu integracji / automatyzacji. Z mojego doświadczenia wynika, że ​​JUnit jest tworzony od podstaw do testów jednostkowych i jest teraz przesuwany w kierunku wyższych poziomów testowania, co sprawia, że ​​IMO jest niewłaściwym narzędziem do tego zadania. TestNG radzi sobie dobrze w testowaniu jednostkowym, a dzięki solidnemu udostępnianiu danych i znakomitym możliwościom wykonywania testów działa jeszcze lepiej na poziomie testów integracji / automatyzacji.

A teraz to, co uważam za osobną kwestię, jak pisać dobrze ustrukturyzowane, czytelne i możliwe do utrzymania testy. Większość to jestem pewien, że wiesz, ale takie rzeczy Wzór Fabryki , Wzór polecenia i PageObjects (jeśli testowania stron WWW) są niezbędne, to jest bardzo ważne, aby mieć warstwę abstrakcji pomiędzy co twój testowej (SUT) i co rzeczywiste testu jest (twierdzenia logiki biznesowej). Aby mieć o wiele ładniejsze stwierdzenia, możesz użyć Hamcrest . Skorzystaj z dziedziczenia / interfejsów javas, aby zmniejszyć liczbę powtórzeń i wymusić podobieństwo.

Prawie zapomniałem, użyj również wzorca testowego konstruktora danych , to w połączeniu z adnotacją dostawcy danych TestNG jest bardzo przydatne.

Moja opinia o tym, co sprawia, że ​​TestNG jest naprawdę dużo potężniejszy:

1.  JUnit still requires the before/after class methods to be static, which limits
    what you can do prior to the running of tests, TestNG never has this issue.

2.  TestNG @Configuration methods can all take an optional argument to their 
    annotated methods in the form of a ITestResult, XmlTest, Method, or 
    ITestContext.  This allows you to pass things around that JUnit wouldn't 
    provide you.  JUnit only does this in listeners and it is limited in use.

3.  TestNG comes with some pre-made report generation classes that you can copy
     and edit and make into your own beautiful test output with very little 
     effort. Just copy the report class into your project and add a listener 
     to run it.  Also, ReportNG is available.

4.  TestNG has a handful of nice listeners that you can hook onto so you can do
     additional AOP style magic at certain phases during testing.