Dlaczego warto używać JUnit do testowania?

Piszemy testy, aby zweryfikować poprawność działania programu.

Sprawdzanie poprawności działania programu poprzez sprawdzenie zawartości instrukcji wyjściowych przy użyciu oczu jest procesemmanual , a dokładniejVisual .

Można by argumentować, że

kontrola wzrokowa działa , sprawdzam, czy kod robi to, do czego jest przeznaczony zrobić, dla tych scenariuszy i kiedy widzę, że jest poprawny, jesteśmy dobrzy do idź.

Po pierwsze, dobrze, że jesteś zainteresowany tym, czy kod działa poprawnie. To dobrze. Jesteś przed zakrętem! Niestety, istnieją problemy z tym podejściem.

Pierwszy problem z oględzinami polega na tym, że jesteś nieszczęśliwym wypadkiem spawalniczym i nigdy nie będziesz w stanie ponownie sprawdzić poprawności kodu.

Drugi problem polega na tym, że używana para oczu jest ściśle powiązana z mózgiem właściciela oczu. Jeśli autor kodu posiada również Oczy używane w procesie kontroli wzrokowej, proces weryfikacji poprawności uzależniony jest od wiedzy o programie internalizowanej w mózgu Inspektora wzrokowego.

Trudno jest nowej parze oczu wejść i zweryfikować poprawność kodu tylko dlatego, że nie współpracują z mózgiem oryginalnego kodera. Właściciel drugiej pary oczu będzie musiał porozmawiać z oryginalnym autorem kodu w aby w pełni zrozumieć dany kod. Rozmowa jako sposób dzielenia się wiedzą jest notorycznie zawodna. Punkt, który jest sporny, jeśli oryginalny koder jest niedostępny dla nowej pary oczu. W tym przypadku nowa para oczu musi odczytać oryginalny kod.

Czytanie kodu innych osób, który nie jest objęty testami jednostkowymi, jest trudniejsze niż czytanie kodu, który ma powiązane testy jednostkowe. W najlepszym razie czytanie kodu innych ludzi jest trudną pracą, w najgorszym jest to najbardziej turgid zadanie w inżynierii oprogramowania. Nie bez powodu pracodawcy, reklamując oferty pracy, podkreślają, że projekt jest zielony (lub zupełnie nowy). Pisanie kodu od podstaw jest łatwiejsze niż modyfikowanie istniejącego kodu i tym samym sprawia, że reklamowana praca wydaje się bardziej atrakcyjna dla potencjalnych pracowników.

W testach jednostkowych dzielimy kod na jego części składowe. Dla każdego komponentu ustawiamy nasze stoisko z informacją o tym, jak powinien zachowywać się program . Każdy test jednostkowy mówi opowieść o tym, jak ta część programu powinna działać w konkretnym scenariuszu. Każdy test jednostkowy jest jak klauzula w umowie, która opisuje, co powinno się wydarzyć z punktu widzenia kodu klienta.

Oznacza to, że nowa para oczu ma dwapasma żywej i dokładnej dokumentacji danego kodu.

Po pierwsze mają sam kod, implementację, Jak kod został wykonany ; Po drugie wiedzą, że oryginalny koder opisane w zestawie formalnych stwierdzeń, które opowiadają o tym, jak ten kod ma się zachowywać.

Testy jednostkowe przechwytują i formalnie opisują wiedzę, którą autor posiadał podczas implementacji klasy. Dostarczają one opis tego, jak Klasa zachowuje się, gdy jest używana przez Klienta.

Masz rację kwestionując przydatność robienia tego, ponieważ możliwe jest pisanie testów jednostkowych, które są bezużyteczne, nie obejmują całego kodu, stają się czerstwe lub nieaktualne i tak dalej. W jaki sposób możemy zapewnić, że testy jednostkowe nie tylko naśladują, ale udoskonalają proces kompetentnego, sumiennego autora, sprawdzającego w czasie wykonywania wypowiedzi wyjściowych swojego kodu? Napisz najpierw test jednostkowy, a następnie napisz kod, aby ten test przeszedł pomyślnie. Kiedy skończysz, pozwól komputerom uruchomić testy, są szybkie są świetne w wykonywaniu powtarzalnych zadań są idealnie dopasowane do pracy.

Zapewnij jakość testu, przeglądając je za każdym razem dotknij kodu, który testują i uruchom testy dla każdej kompilacji. Jeśli test się nie powiedzie, napraw go natychmiast.

Automatyzujemy proces uruchamiania testów tak, aby były one uruchamiane za każdym razem, gdy robimy build projektu. Automatyzujemy również generowanie raportów dotyczących zasięgu kodu, które określają, jaki procent kodu jest objęty i wykorzystywany przez testy. Dążymy do wysokich procentów. Niektóre firmy zapobiegną sprawdzaniu zmian kodu do kontroli kodu źródłowego, jeśli nie mają wystarczających testy jednostkowe napisane w celu opisania wszelkich zmian w zachowaniu kodu. Zazwyczaj druga para oczu sprawdza zmiany w kodzie w połączeniu z autorem zmian. Recenzent będzie przejść przez zmiany zapewnić, że zmiany zrozumiałe i wystarczająco objęte testami. Tak więc proces przeglądu jest ręczny, ale gdy testy (testy jednostkowe i integracyjne oraz ewentualnie testy akceptacji użytkownika) przechodzą ten proces przeglądu ręcznego, stają się częścią automatycznego procesu budowania. Są to za każdym razem, gdy dokonywana jest zmiana. Serwer continuous-integration wykonuje to zadanie jako część procesu budowania.

Testy, które są uruchamiane automatycznie, utrzymują integralność zachowania kodu i pomagają zapobiec przyszłym zmianom w bazie kodu przed złamaniem kodu .

Wreszcie, dostarczenie testów pozwala agresywnie przeliczać kod , ponieważ możesz bezpiecznie wprowadzać duże ulepszenia kodu, wiedząc, że Twoje zmiany nie pękną istniejące testy.

Jest zastrzeżenie do Test Driven Development i jest to, że musisz pisać kod z okiem, aby był testowalny. Polega to na kodowaniu interfejsów i użyciu technik takich jak wstrzykiwanie zależności do tworzenia instancji współpracujących obiektów. Sprawdź pracę Kenta Becka , który bardzo dobrze opisuje TDD. Poszukaj kodowanie do interfejsów i zbadaj wzorce projektowe

Kiedy testujesz używając czegoś takiego jak System.testujesz tylko mały podzbiór możliwych przypadków użycia. Nie jest to zbyt dokładne, gdy mamy do czynienia z systemami, które mogą przyjmować niemal nieskończoną ilość różnych wejść.

Testy jednostkowe są zaprojektowane tak, aby umożliwić szybkie uruchamianie testów w aplikacji przy użyciu bardzo dużego i zróżnicowanego zestawu różnych danych wejściowych. Ponadto najlepsze testy jednostkowe uwzględniają również przypadki graniczne, takie jak dane wejściowe, które leżą bezpośrednio na krawędź tego, co jest uważane za ważne.

Dla człowieka, aby przetestować wszystkie te różne wejścia może trwać tygodnie, podczas gdy to może zająć kilka minut dla maszyny.

Pomyśl o tym w ten sposób: nie "testujesz" czegoś, co będzie statyczne. Twoja aplikacja najprawdopodobniej przechodzi ciągłe zmiany. Dlatego te testy jednostkowe są przeznaczone do uruchamiania w różnych punktach cyklu kompilacji lub wdrażania. Chyba największą zaletą jest to:

Jeśli złamiesz coś w Twoim kodzie, będziesz o tym wiedział teraz , nie po wdrożeniu, Nie kiedy tester QA złapie błąd, Nie kiedy twoi klienci anulują. Będziesz miał również większą szansę na naprawienie usterki natychmiast, ponieważ jest jasne, że rzecz, która złamała część kodu, o której mowa, najprawdopodobniej zdarzyła się od ostatniej kompilacji. W ten sposób ilość prac dochodzeniowych wymaganych do rozwiązania problemu jest znacznie zmniejszona.

Testy jednostkowe zapewniają, że kod działa zgodnie z przeznaczeniem. Są one również bardzo pomocne, aby upewnić się, że kod nadal działa zgodnie z przeznaczeniem na wypadek, gdybyś musiał go później zmienić, aby zbudować nowe funkcje, aby naprawić błąd. Wysoki zakres testowy kodu pozwala na dalsze rozwijanie funkcji bez konieczności wykonywania wielu testów ręcznych.

Istnieje również kilka bardziej zaawansowanych funkcji są w JUnit jak like

Twierdzenia

Niektóre z tych metod are

1. fail([message]) - pozwala na niepowodzenie testu. Może być używany do sprawdzania, czy pewna część kodu nie została osiągnięta. Lub mieć nieudany test przed zaimplementowaniem kodu testowego.
2. assertTrue(true) / assertTrue(false) - zawsze będzie prawda / fałsz. Może być używany do predefiniowania wyniku testu, jeśli test nie jest jeszcze realizowany.
3. assertTrue([message,] condition) - sprawdza, czy wartość logiczna condition Jest Prawdziwa.
4. assertEquals([message,] expected, actual) - sprawdza, czy dwie wartości są sobie równe (zgodnie z metodą equals, jeśli jest zaimplementowana, w przeciwnym razie za pomocą [[9]} porównanie referencji). Uwaga: w przypadku tablic sprawdzana jest Referencja, a Nie Zawartość, użyj do tego assertArrayEquals([message,] expected, actual).
5. assertEquals([message,] expected, actual, delta) - sprawdza, czy dwie wartości float lub double znajdują się w pewnej odległości od siebie, kontrolowane przez wartość delta.
6. assertNull([message,] object) - sprawdza, czy obiekt jest null

I tak dalej. Zobacz pełną wersję Javadoc dla wszystkich przykładów tutaj .

Apartamenty

Z zestawami testowymi, można w pewnym sensie połącz wiele klas testowych w jedną jednostkę, aby móc wykonać je wszystkie naraz. Prosty przykład, łącząc klasy testowe MyClassTest i MySecondClassTest W jeden pakiet o nazwie AllTests:

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ MyClassTest.class, MySecondClassTest.class })
public class AllTests { } 

Dodałem jakiś inny System.out can NOT do:

• Uniezależnić każdy przypadek testowy (to ważne)

  JUnit może to zrobić: za każdym razem, gdy zostanie utworzona nowa instancja test case i zostanie wywołana @Before.

• Oddziel kod testowy od źródła

  JUnit może to zrobić.

• Integracja z CI

  JUnit może to zrobić z Ant i Maven.

• Łatwe układanie i łączenie przypadków testowych

  JUnit potrafi zrobić @Ignore i przetestować Apartament.

• Łatwy do sprawdzenia wynik

  JUnit oferuje wiele metod (assertEquals, assertSame...)

• Mock i stub sprawiają, że skupiasz się na module testowym.

  JUnit może to zrobić: używając mocka i Stuba, skonfigurujesz poprawne urządzenie i skup się na logice modułu testowego.

Główną zaletą JUnit jest to, że jest zautomatyzowany, a nie ręczne sprawdzanie za pomocą wydruków. Każdy test, który piszesz, pozostaje w Twoim systemie. Oznacza to, że jeśli dokonasz zmiany, która ma nieoczekiwany efekt uboczny, twój test ją złapie i zawiedzie, zamiast pamiętać o ręcznym testowaniu wszystkiego po każdej zmianie.

JUnit jest frameworkiem do testów jednostkowych dla języka programowania Java. Jest to ważne w rozwoju test driven i należy do rodziny frameworków do testowania jednostkowego znanych zbiorczo jako xUnit.

JUnit promuje ideę "najpierw testowanie, potem kodowanie", która kładzie nacisk na ustawienie danych testowych dla kawałka kodu, który może być najpierw przetestowany, a następnie zaimplementowany . Takie podejście jest jak " przetestuj trochę, kod trochę, przetestuj trochę, kod trochę..."co zwiększa Produktywność i stabilność kodu programu, która zmniejsza stres programisty i czas spędzony na debugowaniu.

Funkcje JUnit jest open source framework, który jest używany do pisania i uruchamiania testów.

Zapewnia adnotację w celu identyfikacji metod badawczych.

Dostarcza twierdzeń do testowania oczekiwanych wyników.

Zapewnia biegaczy do testów biegowych.

Testy JUnit pozwalają na szybsze pisanie kodu co zwiększa jakość

JUnit jest elegancko proste. Jest mniej złożony i zajmuje mniej czasu.

Testy JUnit mogą być uruchamiane automatycznie, sprawdzają własne wyniki i zapewniają natychmiastową informację zwrotną. Nie ma potrzeby ręcznego przeczesywania raportu wyników badań.

Testy JUnit mogą być zorganizowane w Pakiety testowe zawierające przypadki testowe, a nawet inne pakiety testowe.

Junit pokazuje postęp testu na pasku, który jest zielony, jeśli test idzie dobrze i zmienia kolor na czerwony, gdy test się nie powiedzie.

Mam nieco inne spojrzenie na to, dlaczego JUnit jest potrzebny.

1. Zamiast System.out możemy dodać if(value1.equals(value2)) i zwrócić 0 lub -1 lub komunikat o błędzie. W tym przypadku potrzebujemy "głównej" klasy testowej, która uruchamia wszystkie te metody i sprawdza wyniki i utrzymuje, które przypadki testowe zawiodły, a które zostały zdane.

2. Jeśli chcesz dodać więcej testów musisz dodać je do ta "główna" klasa testowa, jak również. Zmiany w istniejącym kodzie. Jeśli chcesz automatycznie wykrywać przypadki testowe z klas testowych, musisz użyć reflection.

3. Wszystkie twoje testy i twoja główna klasa do uruchomienia testów nie są wykrywane przez eclipse i musisz napisać niestandardowe konfiguracje debugowania/uruchamiania, aby uruchomić te testy. Nadal nie widzisz tych całkiem zielonych / czerwonych wyjść.

Oto co robi JUnit:

1. Posiada metody assertXXX(), które są przydatne do drukowania pomocnych komunikatów o błędach z warunków i przekazywania wyników do klasy "main".

2. "main" Klasa nazywa się runner, który jest dostarczany przez JUnit, więc nie musimy pisać żadnych. I wykrywa metody testowe automatycznie przez odbicie. Jeśli dodasz nowe testy z adnotacją @Test, zostaną one automatycznie wykryte.

3. JUnit ma również integrację z eclipse i Maven/gradle, więc łatwo jest uruchamiać testy i nie będziesz musiał pisać niestandardowe konfiguracje uruchamiania.

Nie jestem ekspertem od JUnit, więc to, co teraz zrozumiałem, dodam więcej w przyszłości.

Nie możesz napisać żadnego przypadku testowego bez użycia frameworku testowego, inaczej będziesz musiał napisać swój testowy Framework, aby oddać sprawiedliwość swoim testowym przypadkom. Oto kilka informacji o JUnit Framework oprócz tego, że można używać TestNG framework .

Co To jest Junit?

Junit jest szeroko stosowanym frameworkiem testowym wraz z językiem programowania Java. Możesz użyć tej struktury automatyzacji zarówno do testowania jednostkowego, jak i interfejsu użytkownika testing.It pomaga nam zdefiniować przepływ wykonania naszego kodu z różne adnotacje. Junit opiera się na idei "najpierw testowanie, a potem kodowanie", która pomaga nam zwiększyć produktywność przypadków testowych i stabilność kodu.

Ważne cechy testów Junit -

1. jest to open source testing framework pozwalający użytkownikom pisać i uruchamiać przypadki testowe skutecznie.
2. zapewnia różne rodzaje adnotacji w celu identyfikacji metod badawczych.
3. zapewnia różne rodzaje twierdzeń w celu weryfikacji wyników przypadku testowego egzekucja.
4. daje również biegaczom testowym możliwość skutecznego prowadzenia testów.
Jest to bardzo proste i pozwala zaoszczędzić czas.
5. zapewnia sposoby organizowania spraw testowych w formie kombinezonów testowych.
6. daje wyniki testów w prosty i elegancki sposób.
Można zintegrować jUnit z Eclipse, Android Studio, Maven & Ant, Gradle i Jenkins.]}

JUNIT jest metodą, która jest zwykle akceptowana przez Java developer. W przypadku gdy mogą one zapewnić podobne oczekiwane dane wejściowe do funkcji i odpowiednio zdecydować, że pisany kod jest doskonale napisany lub jeśli przypadek testowy nie powiedzie się, może być również konieczne wdrożenie innego podejścia. JUNIT sprawi, że rozwój będzie szybki i zapewni 0 defektów w funkcji.

JUNIT: OBSERWUJ I DOSTOSUJ

Oto moja perspektywa JUNIT.

JUNIT może być używany do,
1) obserwuj zachowanie systemu po dodaniu nowej jednostki do tego systemu.
2) Dokonaj regulacji w systemie, aby powitać "nową" jednostkę w systemie.
Co? Dokładnie.

Real life np.

Kiedy twój krewny odwiedza twój pokój w akademiku,
1) będziesz udawał, że jesteś bardziej odpowiedzialny.
2) zachowasz wszystkie rzeczy tam, gdzie one powinno być, jak buty w stojaku na buty nie na krześle, ubrania w szafie nie na krześle.
3) pozbędziesz się całej kontrabandy.
4) rozpoczniesz oczyszczanie w każdym posiadanym urządzeniu.

W terminach programowania

System: Twój kod
Jednostka: nowa funkcjonalność.
Ponieważ JUnit framework jest używany dla języka JAVA, więc JUNIT = JAVA UNIT (może być).

Załóżmy, że masz już dobrze kuloodporny kod, ale pojawił się nowy wymóg i musisz dodać nowe wymagania w kodzie. To nowe wymaganie może złamać kod dla niektórych danych wejściowych (testcase).

Łatwym sposobem dostosowania tej zmiany jest użycie testów jednostkowych (JUNIT).
W tym celu powinieneś napisać wiele testów dla swojego kodu podczas budowania bazy kodowej. A gdy pojawi się nowy wymóg, po prostu uruchom wszystkie przypadki testowe, aby sprawdzić, czy jakikolwiek przypadek testowy się nie powiedzie. Jeśli nie, to jesteś BadA * * artystą i jesteś gotowy do wdrożenia nowego kodu.
Jeśli któraś z testów zawiedzie to zmieniasz Twój kod i ponownie uruchom testcases, aż otrzymasz zielony status.