Co to jest testowanie jednostkowe i jak to zrobić? [duplikat]

Co to jest testowanie jednostkowe?

Testy jednostkowe po prostu sprawdzają, czy poszczególne jednostki kodu (głównie funkcje) działają zgodnie z oczekiwaniami. Zazwyczaj piszesz przypadki testowe samodzielnie, ale niektóre mogą być generowane automatycznie.

Wyjście z testu może być tak proste, jak wyjście konsoli, do "green light " W interfejsie graficznym, takim jak NUnit , lub inny framework specyficzny dla języka.

Wykonywanie testów jednostkowych ma być proste, generalnie testy są napisane w forma funkcji, która określi, czy zwracana wartość jest równa wartości, której oczekiwałeś podczas pisania funkcji (lub wartości, której oczekujesz , gdy W końcu ją napiszesz - nazywa się to Test Driven Development , gdy piszesz testy jako pierwszy).

Jak wykonać testy jednostkowe?

Wyobraź sobie bardzo prostą funkcję, którą chciałbyś przetestować:

int CombineNumbers(int a, int b) {
    return a+b;
}

Kod testu jednostkowego wyglądałby jak to:

void TestCombineNumbers() {
    Assert.IsEqual(CombineNumbers(5, 10), 15); // Assert is an object that is part of your test framework
    Assert.IsEqual(CombineNumbers(1000, -100), 900);
}

Kiedy wykonasz testy, zostaniesz poinformowany, że te testy przeszły pomyślnie. Teraz, gdy zbudowałeś i uruchomiłeś testy, wiesz, że ta konkretna funkcja lub jednostka będzie działać zgodnie z oczekiwaniami.

Teraz wyobraź sobie, że pojawia się inny programista i zmienia funkcję CombineNumbers() dla wydajności, lub z innego powodu:

int CombineNumbers(int a, int b) {
    return a * b;
}

Kiedy programista uruchomi testy, które utworzyłeś dla tej bardzo prostej funkcji, zobaczy, że pierwsza Assert nie powiedzie się, a oni teraz wiedz, że konstrukcja jest zepsuta.

Powinny być wykonywane tak często, jak to możliwe. Kiedy wykonujesz testy w ramach procesu rozwoju, Twój kod będzie automatycznie zaprojektowany lepiej niż Jeśli po prostu napisałeś funkcje, a następnie ruszyłeś dalej. Również koncepcje takie jak Dependency Injection będą ewoluować naturalnie w Twoim kodzie.

Najbardziej oczywistą korzyścią jest świadomość, że gdy zmiana jest wykonane, żadne inne jednostki kodu nie miały wpływu na to, jeśli wszystkie przechodzą testy.

Co?..

Metodologia automatycznego testowania kodu przed zestawem testów, zaprojektowana w celu wyegzekwowania pożądanych wyników i zarządzania zmianami.

"jednostka" w tym sensie jest najmniejszym atomowym składnikiem kodu, który ma sens do testowania, zazwyczaj metodą jakiejś klasy na przykład. Częścią tego procesu jest tworzenie obiektów stub (lub "mocks"), które pozwalają na pracę z jednostką jako niezależnym obiektem.

Jak...

Prawie zawsze, proces testowania jednostkowego jest wbudowany w IDE (lub poprzez rozszerzenia) tak, że wykonuje testy z każdą kompilacją. Istnieje wiele frameworków wspomagających tworzenie testów jednostkowych (a nawet mockowych obiektów), często nazywanych fooUnit (por. jUnit, xUnit, nUnit). Ramy te zapewniają sformalizowany sposób tworzenia testów.

Kiedy...

prawie zawsze. Bardzo małe, odrzucane projekty mogą nie być tego warte, ale tylko wtedy, gdy jesteś pewien, że naprawdę są odrzucane. W teorii każdy program zorientowany obiektowo jest testowalny jednostkowo, ale niektóre pattrny projektowe utrudniają to. Notorycznie wzór Singletona jest problematyczny, gdzie odwrotnie struktura iniekcji zależnościowej jest bardzo zorientowana na testy jednostkowe.

Co to jest unittesting? To trudne do zdefiniowania. Na poziomie technicznym budujesz funkcje, które wywołują funkcje w bazie kodowej i sprawdzają wyniki. Zasadniczo dostajesz kilka rzeczy takich jak "assert(5+3) == 8", po prostu bardziej skomplikowane (jak w DataLayer(MockDatabase ()). getUser (). name = = "Dilbert"). Na poziomie widoku narzędzia dodajesz zautomatyzowane, specyficzne dla projektu sprawdzenie, czy wszystko nadal działa tak, jak zakładałeś, że wszystko działa. Jest to bardzo, bardzo pomocne, jeśli refakturujesz i wdrożysz skomplikowane algorytmy. Rezultatem jest na ogół masa dokumentacji i dużo mniej błędów, ponieważ zachowanie kodu jest przypięte.

Buduję przypadki testowe dla wszystkich przypadków brzegowych i uruchamiam je podobnie do działania generacyjnego garbage collector. Podczas gdy implementuję klasę, uruchamiam tylko przypadki testowe, które dotyczą klasy. Kiedy skończę pracować nad tą klasą, uruchamiam wszystkie testy, aby sprawdzić, czy wszystko nadal działa.

Powinieneś przetestować tyle, ile możliwe, o ile kod testowy jest wystarczająco łatwy, aby pozostać nieprzetestowany. Biorąc to pod uwagę, nie, nie wszystko można przetestować w rozsądny sposób. Pomyśl o interfejsach użytkownika. Pomyśl o sterowniku dla promu kosmicznego lub bomby atomowej (przynajmniej nie z czystymi testami JUnit;)). Jednak wiele i wiele kodu można przetestować. Datastruktury są. Algorytmy są. Większość Applicationlogic-klasy są. Więc przetestuj to!

HTH. tetha

Uważam, że najprostszym sposobem na zilustrowanie tego jest przyjrzenie się jakiemuś kodowi. Ta strona startowa na stronie NUnit jest dobrym wprowadzeniem do tego, co i jak

Http://www.nunit.org/index.php?p=quickStart&r=2.5

Czy wszystko można przetestować? Ogólnie jeśli coś wylicza to tak. Kod interfejsu użytkownika to zupełnie inny problem, z którym można sobie poradzić, ponieważ symulowanie użytkowników klikających przyciski jest trudne.

Co należy przetestować? Mam tendencję do pisania testów wokół rzeczy I wiem, że to będzie trudne. Skomplikowane zmiany stanu, krytyczne obliczenia biznesowe, tego typu rzeczy. Generalnie nie martwię się zbytnio testowaniem podstawowych rzeczy wejściowych/wyjściowych, chociaż puryści bez wątpienia powiedzą, że się mylę i Wszystko powinno być przetestowane. Jak wiele innych rzeczy, nie ma właściwej odpowiedzi!

Czym dokładnie jest testowanie jednostkowe? Czy to wbudowany w kod lub uruchamiany jako osobny programy? Albo coś innego?

Od MSDN : głównym celem testów jednostkowych jest pobranie najmniejszego elementu testowalnego oprogramowania w aplikacji, odizolowanie go od reszty kodu i ustalenie, czy zachowuje się dokładnie tak, jak oczekujesz.

Zasadniczo piszesz małe bity kodu, aby przetestować poszczególne bity kodu. W świecie. NET można by uruchomić te małe kawałki kodu przy użyciu czegoś takiego jak NUnit lub MBunit lub nawet wbudowanych narzędzi testowych w visual studio. W Javie można użyć JUnit. Zasadniczo biegacze testowe zbudują Twój projekt, załadują i wykonają testy jednostkowe, a następnie poinformują Cię, czy zdają lub nie.

Jak ty to robisz?

Kiedy należy to zrobić? Czy są czasy lub projekty, aby tego nie robić? Na wszystko można przetestować jednostkowo?

Testy jednostkowe to ogromny temat i do w pełni zrozumieć, w jaki sposób może to najlepiej przynieść ci korzyści polecam zdobycie książki na temat testów jednostkowych, takiej jak " {23]}Test Driven Development by Example ", która da ci dobre zrozumienie pojęć i sposobu zastosowania ich do kodu.

W części "Jak to zrobić":

Myślę, że wprowadzenie do ScalaTest dobrze ilustruje różne style testów jednostkowych.

W części "kiedy to zrobić":

Testowanie jednostkowe to nie tylko testowanie. Wykonując testy jednostkowe, wymusisz również projektowanie oprogramowania w coś, co można przetestować jednostkowo. Wiele osób uważa, że ten projekt jest w większości dobry (TM), niezależnie od innych korzyści z testów.

So one powodem do przeprowadzenia testu jednostkowego jest zmuszenie twojego projektu do czegoś, co, miejmy nadzieję, będzie łatwiejsze do utrzymania, gdyby nie zaprojektowano go do testów jednostkowych.