Co to jest testowanie jednostki?

głosy
193

Widziałem wiele pytań, pytając „jak” do badanej jednostki w określonym języku, ale ma wątpliwości, pytając „co”, „dlaczego” i „po”.

  • Co to jest?
  • Co to dla mnie zrobić?
  • Dlaczego warto z niej korzystać?
  • Kiedy należy używać go (również wtedy, gdy nie)?
  • Jakie są najczęstsze pułapki i błędy
Utwórz 04/08/2008 o 17:27
źródło użytkownik
W innych językach...                            


20 odpowiedzi

głosy
182

testów jednostkowych jest, z grubsza rzecz biorąc, badania bitów kodu w izolacji z kodem testowym. Bezpośrednie korzyści, które przychodzą na myśl, to:

  • Uruchamianie testów staje się zautomatyzowanie-stanie i powtarzalne
  • można przetestować na dużo więcej niż poziom granulowanego wskaż i kliknij poprzez testowanie GUI

Zauważ, że jeśli kod Test zapisuje do pliku, otwiera połączenie z bazą danych lub robi coś przez sieć, to więcej odpowiednio skategoryzowane jako test integracji. Testy integracyjne są dobre, ale nie powinien być mylony z testów jednostkowych. Jednostka kod testowy powinien być krótki, słodkie i szybkie do wykonania.

Innym sposobem, aby spojrzeć na jednostki badań jest to, że piszesz testy pierwszy. Jest to znane jako Test-Driven Development (TDD w skrócie). TDD przynosi dodatkowe korzyści:

  • Nie piszesz spekulacyjny „może muszę to w przyszłości” kodu - wystarczy, aby zdać test
  • Kod napisałeś jest zawsze objęte testami
  • Pisząc pierwszy test, jesteś zmuszony do myślenia o tym, jak chcesz wywołać kod, który zwykle poprawia wygląd kodu w dłuższej perspektywie.

Jeśli nie robisz testów jednostkowych teraz, polecam Ci zacząć na nim. Dostać dobrą książkę, praktycznie każdy xUnit-book zrobi bo koncepcje są bardzo przenoszone między nimi.

Czasami pisanie testy jednostkowe mogą być bolesne. Kiedy robi się w ten sposób, spróbuj znaleźć kogoś, aby ci pomóc, i oprzeć się pokusie, aby „po prostu napisać kod psiakrew”. Testowanie jednostkowe jest bardzo podobny do mycia naczyń. To nie zawsze jest przyjemne, ale zachowuje swoją metaforyczną kuchnia czyste, i naprawdę ma to być czysty. :)


Edit: Jedno nieporozumienie przychodzi do głowy, chociaż nie jestem pewien, czy to jest tak powszechne. Słyszałem, kierownik projektu twierdzą, że testy jednostkowe wykonane zespół napisać cały kod dwukrotnie. Jeśli wygląda i czuje się w ten sposób, dobrze, robisz to źle. Nie tylko pisanie testów zwykle przyspieszyć rozwój, ale także daje wygodny „teraz skończę” wskaźnik, który nie miałby inaczej.

Odpowiedział 04/08/2008 o 17:36
źródło użytkownik

głosy
65

Nie zgadzam się z Danem (choć lepszym wyborem może być po prostu nie odpowiedzieć) ... ale ...

Testy jednostkowe to proces pisania kodu, aby przetestować zachowanie i funkcjonalność systemu.

Oczywiście testuje poprawy jakości kodu, ale to tylko powierzchowne zaletą testów jednostkowych. Rzeczywiste korzyści to:

  1. Sprawiają, że łatwiej zmienić realizację techniczną podczas upewniając się, że nie zmieniają zachowanie (refaktoryzacji). Odpowiednio przetestowane urządzenie kod może być agresywnie refactored / oczyścić z małą szansą zerwania niczego nie zauważając go.
  2. Daj zaufania deweloperów podczas dodawania zachowań lub dokonywania poprawek.
  3. Udokumentować swój kod
  4. Wskazać obszary kodu, które są ściśle powiązane. Trudno kodu testu jednostka, która jest ściśle sprzężona
  5. Zapewnienie środków do korzystania z API i spojrzeć na trudności na początku
  6. Wskazuje metod i klas, które nie są bardzo spójne

Zalecana testów jednostkowych ponieważ jego w swoim interesie, aby dostarczyć w utrzymaniu i jakości produktu do klienta.

Sugeruję użyć go do dowolnego systemu lub części systemu, które modele zachowań w świecie rzeczywistym. Innymi słowy, jest to szczególnie dobrze nadaje się do rozwoju przedsiębiorstwa. Nie chciałbym go używać dla programów / użytkowych jednorazowe. Nie chciałbym używać go do części systemu, które są problematyczne do testu (UI jest typowym przykładem, ale nie zawsze tak jest)

Największą pułapką jest to, że deweloperzy przetestować zbyt dużą jednostkę, albo uznają metodę jednostkę. Jest to szczególnie prawdziwe, jeśli nie rozumieją odwrócenie sterowania - w takim przypadku twoje testy jednostkowe zawsze przekształcić testowania integracyjnego end-to-end. Testy jednostkowe powinny testować indywidualne zachowania - a większość metody mają wiele zachowań.

Największym nieporozumieniem jest to, że programiści nie powinni przetestować. Jedyną złą lub leniwi programiści uwierzyć. Gdyby facet buduje swój dach nie przetestować? Gdyby lekarz wymianie zastawki serca nie przetestować nowy zawór? Tylko programista może sprawdzić, czy jego kod robi to, co zamierzał go zrobić (QA może przetestować przypadki brzegowe - jak kod zachowuje się, kiedy to kazano robić rzeczy programista nie zamierza, a klient może zrobić kontrolę odbioru - czy kod zrobić co co klient zapłacił za to zrobić)

Odpowiedział 04/08/2008 o 17:41
źródło użytkownik

głosy
5

To jest moje zdanie na jej temat. Powiedziałbym, testów jednostkowych jest praktyka pisania testów oprogramowania w celu sprawdzenia, czy prawdziwe oprogramowanie robi to, co ma. To zaczęło się JUnit w świecie Javy i stała się najlepszą praktyką w PHP, jak również z SimpleTest i phpunit . Jest to praktyka rdzeń Extreme Programming i pozwala mieć pewność, że program nadal działa zgodnie z przeznaczeniem po edycji. Jeśli masz wystarczającego pokrycia testowego, można zrobić główną refaktoryzacji, poprawek błędów lub dodać funkcje szybko znacznie mniej strachu wprowadzenia innych problemów.

Jest to najbardziej skuteczny, gdy wszystkie testy jednostkowe mogą być uruchamiane automatycznie.

Testowanie jednostek jest na ogół związane z rozwojem OO. Podstawowym założeniem jest stworzenie skryptu, który konfiguruje środowisko dla kodu a następnie sprawuje go; piszesz twierdzenia, należy określić zamierzone wyjście, które powinien otrzymać, a następnie wykonać skryptu testowego za pomocą ramy, takie jak te wymienione powyżej.

Ramy te uruchomić wszystkie testy na kodzie, a następnie zgłoś się sukces lub niepowodzenie każdego testu. phpunit jest uruchamiany z linii poleceń Linuksa domyślnie, chociaż istnieją interfejsy HTTP dostępny dla niego. SimpleTest jest oparty na sieci Web przez naturę i jest o wiele łatwiej dostać się i działa, IMO. W połączeniu z Xdebug, phpunit może dać zautomatyzowanych statystyki dla pokrycia kodu, które niektórzy ludzie bardzo przydatne.

Niektóre zespoły napisać haki ze swoim repozytorium tak, że testy jednostkowe są uruchamiane automatycznie po zatwierdzić zmiany.

Jest to dobra praktyka, aby zachować swoje testy jednostkowe w tym samym repozytorium jako aplikacji.

Odpowiedział 05/08/2008 o 00:53
źródło użytkownik

głosy
2

Jednostka testowanie jest testowanie jednostki kodu (np jednofunkcyjny) bez potrzeby infrastruktury że jednostka opiera się na kodzie. tj przetestować go w izolacji.

Jeśli, na przykład, funkcja, które testujemy łączy się z bazą danych i wykonuje aktualizację, w badanej jednostki nie może chcieć zrobić aktualizację. byś jakby była próba integracji, ale w tym przypadku tak nie jest.

Więc test jednostka będzie wykonywać funkcje zamknięte w „funkcja” testujesz bez skutków ubocznych aktualizacji bazy danych.

Powiedzieć czynność pobierane niektóre numery z bazy danych, a następnie wykonano obliczenia odchylenia standardowego. Co chcesz przetestować tutaj? Że odchylenie standardowe oblicza się prawidłowo lub że dane są zwracane z bazy danych?

W badanej jednostki po prostu chcesz przetestować, że odchylenie standardowe oblicza się prawidłowo. W teście integracji chcesz przetestować obliczenia odchylenia standardowego i odzyskiwanie bazy danych.

Odpowiedział 15/08/2008 o 18:42
źródło użytkownik

głosy
1

Poszedłem do prezentacji na testowanie jednostkowe w FoxForward 2007 i nigdy nie powiedział niczego do jednostki testowej, który działa z danymi. Po tym wszystkim, jeśli sprawdzenie danych na żywo, wyniki są nieprzewidywalne, a jeśli nie testować na danych żywych, nie jesteś rzeczywiście testuje kod został zapisany. Niestety, to większość kodowania robię te dni. :-)

I wziął szansę na TDD niedawno kiedy pisałem rutynę, aby zapisać i przywrócić ustawienia. Po pierwsze, zweryfikowane, że mogę utworzyć obiekt pamięci masowej. Następnie, że ma metodę, co potrzebne, aby zadzwonić. Potem, że mogę to nazwać. Potem, że mogę przekazać to parametry. Potem, że mogę go przekazywać konkretne parametry. I tak dalej, aż w końcu sprawdzeniu, że byłoby zapisać określonego ustawienia pozwalają mi go zmienić, a następnie odtworzyć go na kilka różnych składni.

I nie dostać się do końca, bo potrzebne-the-rutynowej-now-Cholera, ale to było dobre ćwiczenie.

Odpowiedział 22/08/2008 o 19:10
źródło użytkownik

głosy
1

Co zrobić, jeśli dostaniesz kupę gówna i wydawać się utkniesz w stanie nieustającej porządki, które znamy z dodatkiem każdej nowej funkcji lub kodu może złamać aktualny zestaw ponieważ obecny oprogramowanie jest jak dom karty?

Jak możemy to zrobić testów jednostkowych wtedy?

Zaczynasz małe. Projekt Właśnie dostałem do testów jednostkowych nie miał jeszcze kilka miesięcy temu. Kiedy było to, że niski zasięg, chcemy po prostu wybrać plik, który nie miał pokrycia i kliknij „dodaj testy”.

Teraz jesteśmy aż do ponad 40%, a udało nam się odebrać od większości owoców nisko wiszącej.

(Najlepsze jest to, że nawet przy tak niskim poziomie pokrycia, już napotkasz wielu przypadkach kod robi coś złego, a testowanie złapał go. To ogromna motywatorem do pchania ludzi, aby dodać więcej testów).

Odpowiedział 22/08/2008 o 19:19
źródło użytkownik

głosy
12

Wykruszanie się na filozoficznych zalet testów jednostkowych i TDD Oto kilka z ich kluczowymi „lightbulb” obserwacji, które uderzyło mnie na moich wstępnych pierwszych kroków na drodze do oświecenia TDD (brak oryginału lub koniecznie Aktualności) ...

  1. TDD NIE oznacza pisanie dwukrotnie ilość kodu. kod test jest zazwyczaj dość szybkie i bezbolesne pisać i jest kluczową częścią procesu projektowania i krytycznie.

  2. TDD pomaga uświadomić sobie, kiedy przestać kodowania! Twoje testy daje pewność, że zrobiłeś tyle na teraz i może przestać szczypanie i przejść do następnej rzeczy.

  3. Badania i prace kod razem, aby osiągnąć lepszy kod. Kod może być zły / buggy. Test może być zły / buggy. W TDD jesteś bankowy na szansach obu bycie złym / buggy będących dość niska. Często jego test, który wymaga ustalenia, ale to wciąż dobry wynik.

  4. TDD pomaga zaparcia kodowania. Znasz to uczucie, że masz tak wiele do zrobienia prawie nie wiem od czego zacząć? Jest piątek po południu, jeśli tylko odwlekają na kilka więcej godzin ... TDD pozwala na ciało się bardzo szybko, co myślisz, co musisz zrobić, i dostaje kodowania ruchomych szybko. Ponadto, jak szczury laboratoryjne, myślę, że wszyscy odpowiedzieć na to wielkie zielone światło i pracować ciężej, aby go zobaczyć jeszcze raz!

  5. W podobnym tonie, te typy projektant może zobaczyć, co pracujesz. Mogą wędrować na sok / papieros przerwy / iPhone i powrócić do monitora, który natychmiast daje im wizualną wskazówkę co do miejsca, gdzie dostali się. TDD daje nam coś podobnego. Łatwiej zobaczyć, gdzie mamy do kiedy interweniuje życie ...

  6. Myślę, że to Fowler, który powiedział: „Imperfect testy, prowadzone często, są znacznie lepsze niż doskonałych testów, które nie są zapisane w ogóle”. I zinterpretować to jako danie mi pozwolenie na napisanie testów gdzie myślę, że one najbardziej przydatne, nawet jeśli reszta mojego pokrycia kodu jest dalece niepełna.

  7. TDD pomaga w różnego rodzaju zaskakujący sposób w dół. Dobre testy jednostkowe mogą pomóc dokument coś, co ma robić, mogą pomóc przenieść kod z jednego projektu do drugiego i daje nieuzasadnione poczucie wyższości nad swoimi niebadawczych kolegów :)

Ta prezentacja jest doskonałym wstępem do wszystkich pyszne pociąga za sobą badania dobroć.

Odpowiedział 24/08/2008 o 22:58
źródło użytkownik

głosy
2

Test Driven Development jakby przejęte Test określenie jednostkowych. Jako stary zegar będę wspominając o bardziej ogólną definicję niego.

Test jednostki oznacza także testowanie pojedynczy komponent w większym systemie. Ten pojedynczy element może być dll, exe, klasa biblioteka, itp Może to być nawet jeden system w aplikacji wielo-systemowym. Więc ostatecznie kończy się na tym, jednostka testowa badanie cokolwiek chcesz zadzwonić do jednego kawałka większego systemu.

Można by następnie przenieść się do zintegrowanego systemu testowania lub testując jak wszystkie elementy współpracują ze sobą.

Odpowiedział 24/08/2008 o 23:34
źródło użytkownik

głosy
5

Używam testów jednostkowych, aby zaoszczędzić czas.

Podczas budowania logiki biznesowej (lub dostępu do danych) funkcjonalność testowania często wiązać wpisując rzeczy na wiele ekranów, które mogą lub nie mogą być jeszcze zakończona. Automatyzacja tych badań oszczędza czas.

Dla mnie testy jednostkowe są rodzajem zmodularyzowanego uprzęży testu. Zwykle jest co najmniej jedno badanie na funkcję publiczną. Piszę dodatkowe testy na pokrycie różnych zachowań.

Wszystkie przypadki szczególne, że myśleli o przy tworzeniu kodu mogą być zapisane w kodzie w testach jednostkowych. Testy jednostkowe stać się również źródłem przykładów, w jaki sposób korzystać z kodu.

Jest to o wiele szybciej mi odkryć, że mój nowy kod łamie coś w moich testów jednostkowych następnie sprawdzić w kodzie i mieć jakiś front-end developer znaleźć problem.

Do testowania dostępu do danych Staram się pisać testy, które albo nie mają zmiany lub posprzątać po sobie.

testy jednostkowe nie będą w stanie rozwiązać wszystkie wymagania testowe. Będą one w stanie zaoszczędzić czas rozwoju i części podstawowe testy aplikacji.

Odpowiedział 17/09/2008 o 01:38
źródło użytkownik

głosy
3

Użyj Testivus . Wszystko, co musisz wiedzieć, to właśnie tam :)

Odpowiedział 17/09/2008 o 01:48
źródło użytkownik

głosy
29

Nigdy nie uczono jednostki badań na uniwersytecie, i zajęło mi trochę czasu, aby „dostać” go. Czytałem o tym, poszedł „Ach, prawda, zautomatyzowane testy, które mogłyby być cool Chyba”, a potem zapomniałem o tym.

Zajęło to trochę dłużej, zanim naprawdę zorientowali się punkt: Załóżmy, że pracujesz na dużym systemie i napisać mały moduł. Kompiluje, można umieścić go przez jego kroki, działa świetnie, od razu przejść do następnego zadania. Dziewięć miesięcy wzdłuż linii i dwie wersje później ktoś inny wprowadza zmiany do niektórych pozornie niepowiązanych części programu, a to łamie moduł. Co gorsza, testują ich zmiany, a ich kod działa, ale nie przetestować moduł; cholery, nie może nawet wiedzieć, Twój moduł istnieje .

A teraz masz problem: złamany kod znajduje się na pniu i nikt nawet nie wie. Najlepszym przypadkiem jest tester wewnętrzny znajdzie go przed wami statku, ale kod ustalające, że późno w grze jest drogie. A jeśli nie tester wewnętrzny znajdzie ... dobrze, że można uzyskać bardzo drogie rzeczywiście.

Rozwiązanie to testy jednostkowe. Będą łapać problemy podczas pisania kodu - co jest w porządku - ale można zrobić to ręcznie. Prawdziwy wypłata jest to, że oni złapać problemów dziewięć miesięcy wzdłuż linii, gdy jesteś obecnie nad zupełnie innym projektem, ale letni stażysta myśli, że to wygląda porządniej, jeśli te parametry były w porządku alfabetycznym - a potem testy jednostkowe napisałeś droga powrotna nie powiedzie się, a ktoś rzuca rzeczy na stażysta, dopóki nie zmienia kolejność parametrów powrotem. To „dlaczego” z jednostki testy. :-)

Odpowiedział 19/09/2008 o 13:45
źródło użytkownik

głosy
3

Testowanie jednostek jest o pisaniu kodu, który sprawdza kod aplikacji.

Jednostka część nazwy jest o zamiarze zbadania małych jednostek kodu (jedna metoda na przykład) na raz.

xUnit jest tam, aby pomóc w tym testów - są to ramy, które pomagają w tym. Część, która jest zautomatyzowana biegaczy badań, które mówią ci, co nie i testy, które przechodzą z nich.

Mają także zaplecze do konfiguracji wspólnego kodu, które trzeba w każdym teście przed ręką i zburzyć gdy wszystkie testy zostały zakończone.

Można mieć test, aby sprawdzić, czy oczekiwany wyjątek został rzucony, bez konieczności pisania cały blok try catch siebie.

Odpowiedział 14/03/2010 o 18:19
źródło użytkownik

głosy
40

Główną różnicą testów jednostkowych, w przeciwieństwie do „po prostu otwierając nowy projekt i przetestować ten specyficzny kod” jest to, że zautomatyzowane , co powtarzalne .

Jeśli przetestować swój kod ręcznie, może przekonać się, że kod działa doskonale - w jego obecnym stanie . Ale co o tydzień później, kiedy zanotował niewielką modyfikację w nim? Czy jesteś gotów ponownie przetestować go ponownie ręcznie gdy coś zmienia w kodzie? Najprawdopodobniej nie :-(

Ale jeśli można uruchomić swoje testy w każdej chwili, za pomocą jednego kliknięcia, dokładnie w ten sam sposób, w ciągu kilku sekund , wtedy będzie ci pokazać natychmiast, gdy coś jest zepsute. A jeśli również zintegrować testów jednostkowych do swojego zautomatyzowanego procesu kompilacji, będą ostrzegać do błędów, nawet w przypadkach, gdy pozornie całkowicie niezwiązane zmiana złamał coś w odległej części kodzie - jeśli nawet nie przyszło ci do głowy, że istnieje potrzeba ponownego przetestowania tej konkretnej funkcjonalności.

To jest główną zaletą testów jednostkowych ponad testowania ręcznego. Ale czekaj, jest więcej:

  • testy jednostkowe skrócić pętlę sprzężenia zwrotnego rozwój dramatycznie: z osobnym działem testów może potrwać kilka tygodni, aby wiedzieć, że jest to błąd w kodzie, w którym to czasie zostały już zapomniane znacznie od kontekstu, co może zająć od godziny znaleźć i naprawić błąd; OTOH z testów jednostkowych, cykl sprzężenia zwrotnego jest mierzony w sekundach, a proces bug fix jest zwykle wzdłuż linii z „O sh * t, zapomniałem sprawdzić takim stanie tutaj” :-)
  • testy jednostkowe skutecznie udokumentować (zrozumienie) zachowanie kodu
  • Siły badawcze jednostka do przewartościowania swoich wyborów projektowych, co skutkuje w prostszej konstrukcji, czystsze

Jednostka framework'i z kolei sprawiają, że łatwo można napisać i uruchomić swoje testy.

Odpowiedział 14/03/2010 o 18:20
źródło użytkownik

głosy
3

Testy jednostkowe to praktyka, aby upewnić się, że funkcja lub moduł, który masz zamiar realizować będzie zachowywać się zgodnie z oczekiwaniami (wymagań), a także upewnić się, jak zachowuje się w sytuacjach podobnych do warunków brzegowych oraz nieprawidłowych danych wejściowych.

xUnit , NUnit , MbUnit itp są narzędzia, które pomogą Ci w pisaniu testów.

Odpowiedział 14/03/2010 o 18:22
źródło użytkownik

głosy
4

Biblioteki jak NUnit , xUnit lub JUnit to tylko obowiązkowe, jeśli chcesz rozwijać swoje projekty przy użyciu TDD podejście spopularyzowany przez Kent Beck:

Możesz przeczytać Wprowadzenie do Test-Driven Development (TDD) lub książka Kent Beck Test-Driven Development: dobry przykład .

Następnie, jeśli chcesz mieć pewność, że testy obejmują „dobrą” część kodu, można użyć oprogramowania jak NCover , JCover , PartCover czy cokolwiek innego. Powiedzą ci procentu pokrycia kodu. W zależności od tego ile jesteś biegły w TDD, będziesz wiedzieć, jeśli już praktykowane jest wystarczająco dobrze :)

Odpowiedział 14/03/2010 o 18:22
źródło użytkownik

głosy
2

Przede wszystkim, czy mówienie o testów jednostkowych lub innych rodzajów testów automatycznych (Integracja, obciążenia, testowanie interfejsu itd.), Klucz różnica od tego, co sugeruje, że jest zautomatyzowane, powtarzalny i nie wymaga żadnych zasobów ludzkich do spożycia (= nikt nie ma do przeprowadzenia testów, zwykle prowadzony przy naciśnięciu przycisku).

Odpowiedział 14/03/2010 o 18:22
źródło użytkownik

głosy
3

Myślę, że punkt, że nie rozumieją, że jednostka testowania ramy jak NUnit (i podobne) pomoże Ci w automatyzacji małych i średnich testów. Zazwyczaj można uruchomić testy w GUI (jest to przypadek z NUnit , na przykład), po prostu klikając na przycisk, a następnie - miejmy nadzieję - patrz pasek postępu zatrzymać się na zielono. Jeśli okaże czerwony, ramy pokazuje których test zakończył się niepowodzeniem i co dokładnie poszło źle. W normalnym badanej jednostki, często używać twierdzeń, np Assert.AreEqual(expectedValue, actualValue, "some description")- tak czy dwie wartości są równe widać błąd mówiąc „trochę opis: oczekuje <expectedValue> ale <actualValue>”.

Tak jak testowanie jednostkowe wniosek zapewni wprowadzenie testowania szybsze i dużo bardziej wygodne dla programistów. Można uruchomić wszystkie testy jednostkowe przed popełnieniem nowego kodu tak, aby nie przerwać proces budowania innych deweloperów na tym samym projekcie.

Odpowiedział 14/03/2010 o 18:25
źródło użytkownik

głosy
7

Chciałbym polecić xUnit Testing wzorów książkę Gerard Meszaros. Jest to duży, ale jest doskonałym źródłem informacji na temat testów jednostkowych. Oto link do jego strony internetowej, gdzie omawia podstawy testów jednostkowych. http://xunitpatterns.com/XUnitBasics.html

Odpowiedział 14/03/2010 o 19:10
źródło użytkownik

głosy
1

Ten odpowiada, dlaczego należy robić testów jednostkowych.


Do 3 filmów poniżej testów jednostkowych obejmują w JavaScript, ale ogólne zasady mają zastosowanie w większości języków.

Testy jednostkowe: Minuty Teraz Zapisz godzin później - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unit Testing (bardzo dobry) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Pisanie sprawdzalne JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo


Teraz jestem po prostu uczenie się na ten temat, więc nie może być w 100% poprawne i nie więcej, niż to, co ja tutaj opisuję, ale moja podstawowa znajomość testów jednostkowych jest, aby napisać kod testowy (która jest oddzielona od swojej Kod główny), który wywołuje funkcję w głównym kodu z wejściowych (argumentów), że funkcja wymaga, a kod następnie sprawdza, czy wróci poprawną wartość powrotną. Jeśli robi się z powrotem prawidłową wartość testowania ramy urządzenia, które używasz do uruchamiania testów pokazuje zielone światło (wszystko dobrze), jeżeli wartość jest nieprawidłowy pojawi się czerwone światło, a następnie uda się rozwiązać problemu od razu przed wami zwolnić nowego kodu do produkcji, bez testowania może nie rzeczywiście połów błąd.

Tak piszesz testy dla ciebie bieżącego kodu i tworzenia kodu tak, że przechodzi test. Miesiące później ty lub ktoś inny trzeba zmodyfikować funkcję w głównym kodzie, bo wcześniej trzeba było już napisany kod test dla tej funkcji możesz teraz uruchomić ponownie i test może zakończyć się niepowodzeniem, ponieważ koder wprowadzony błąd logiczny w funkcji lub powrót coś zupełnie inny niż to, co ta funkcja ma powrotu. Ponownie bez testu w miejscu, że błąd może być trudne do wyśledzenia, gdyż może to mieć wpływ na inny kod, jak również i przejdzie niezauważony.


Także fakt, że masz program komputerowy, który działa poprzez swój kod i testuje go, zamiast ręcznie robi to na stronie przeglądarki, strony oszczędza czas (testy jednostkowe dla JavaScript). Powiedzmy, że zmodyfikować funkcję, która jest używana przez jakiś skrypt na stronie internetowej i działa wszystko dobrze dla swojego nowego przeznaczeniem. Ale niech też powiedzieć argumentów sake, że istnieje inna funkcja masz gdzieś w kodzie, który zależy od tego nowo zmodyfikowanej funkcji na to, aby działać poprawnie. Ta funkcja zależna mogą teraz przestać działać z powodu zmian, które zostały wprowadzone do pierwszej funkcji, jednak bez testów w miejscu, które są uruchamiane automatycznie przez komputer nie zauważy, że istnieje problem z tej funkcji, dopóki nie zostanie właściwie wykonane i musisz ręcznie przejść do strony internetowej, która zawiera skrypt, który wykonuje funkcję zależną, dopiero wtedy można zauważyć, że jest to błąd z powodu zmian, które wprowadzone w pierwszej funkcji.

Powtórzyć, mając testy, które są uruchamiane przy opracowywaniu aplikacji złapie tego rodzaju problemów, jak jesteś kodowania. Nie mając testy w miejscu trzeba by ręcznie przejść przez cały aplikacji i nawet to może być trudne do wykrycia błędu, naiwnie wysłaniu go do produkcji i po chwili użytkownik rodzaj wysyła raport o błędzie (co nie będzie tak dobry, jak komunikaty o błędach w ramach testów).


Jest to dość mylące, gdy po raz pierwszy usłyszeć przedmiotu i myślisz sobie, nie jestem już testowania mojego kodu? I kod, który napisałeś pracuje jak to ma już „dlaczego muszę kolejny ramy?” ... Tak jesteś już testuje swój kod, ale komputer jest lepiej to robić. Po prostu trzeba napisać tyle dobrych testy dla funkcji / jednostki kodu raz, a reszta jest pod opieką dla Ciebie przez potężnego procesora zamiast konieczności ręcznie sprawdzić, czy wszystko z kodem nadal pracuje po dokonaniu zmian Twój kod.

Ponadto, nie trzeba do jednostki przetestować kod, jeśli nie chcesz, ale to się opłaca jako podstawy projektu / code zaczyna rosnąć większe szanse jako błędy wprowadzania podwyżek.

Odpowiedział 18/07/2015 o 18:34
źródło użytkownik

głosy
0

Jednostka testowanie i TDD w ogóle pozwala na krótsze cykle opinię o oprogramowaniu piszesz. Zamiast dużej fazę testową na samym końcu realizacji, to stopniowo testować wszystko co piszesz. To zwiększa jakość kodu bardzo, jak od razu zobaczyć, gdzie może mieć błędy.

Odpowiedział 03/05/2017 o 09:33
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more