Informacje o testach - ogólne i szczegółowe

0

Serdecznie witam.
Prosiłbym o rady i informacje o tym jak testować w sposób odpowiedni nasze kody - kody programistów.

Pozwolę sobie podzielić moje pytania w podpunkty, tak by ułatwić każdemu rozeznanie oraz możliwie najłatwiej dać pole do popisu przy odpowiedzi :)

1.) Czy kod/y test/ów powinien znajdować się w klasie, którą testuje? Czy może stworzyć osobną klasę np "Testklient"?
Czy może jeszcze inaczej - stworzyć osobną klasę ogólną do testowania np "testujWszystko" i tam kody testów każdej klasy w odpowiednich funkcjach?

2.) Kod testu polega na tym, aby ustalić czy dany fragment działa prawidłowo. W związku z tym należy po prostu testować dany fragment na wszystkie możliwe sposoby? Wywoływać funkcje z różnymi parametrami itd?

3.) Kod testów powinien zostawać po zakończeniu testu, ponieważ ułatwia to testowanie w następnych etapach projektu. Czy taka sama zasada obowiązuje, gdy projekt jest już ukończony? Czy wtedy nadal kody testów powinny zostać w programie?

4.) Jakie rodzaje testów jeszcze istnieją i czym różnią się od testów jednostkowych? Chodzi tu o przykład praktyczny, gdyż teoria jest nieco zamącona.

5.) Wyczytałem, że kod testujący najlepiej pisać przed kodem właściwym (produkcyjnym). Czy to prawda?

Byłbym niezmiernie wdzięczny za wyjaśnienie mi tych kwestii dotyczących testowania :)
jeśli to ważne (bo może ktoś chce podać prosty przykład) to pisze w C#.

Pozdrawiam.

0
  1. Choćby testy użyteczności. Sadzasz użytkownika przed aplikacją i niech się przeklika i powie jak bardzo interfejs ssie. Albo testy wydajnościowe. Albo testy penetracyjne - bezpieczeństwa.
  2. W podejściu TDD - tak. Najpierw piszesz test, potem piszesz kod, który w założeniu ma spełnić test.
0

#NIE! Bo po co? Zresztą końcowy produkt nie powinien zawierać testów.
#w sytuacji idealnej tak, zwykle jest to nieosiągalne, zwykle stawia się wymóg na pokrycie kodu testami
#kod testów jest nierozerwalny z testowanym kodem. Głównym celem jest systematyczne sprawdzanie, czy czegoś się nie popsuło po wprowadzeniu poprawki lub nowego feaure'a. Szczególnie jest to ważne, w pracy zespołowej i gdy skład zespołu się zmienia.
#jednostkowe (testowane są fragmenty kodu), funkcjonalne (testujesz kod jako całość) - te są najważniejsze i zwykle zautomatyzowane. Jest jeszcze użyteczności, wydajnościowe (perfomance), obciążeniowe, bezpieczeństwa, .... (więcej grzechów nie pamiętam).
#To jest tylko koncepcja jak powinno tworzyć się kod, zwykle tak dobrze nie ma, bo częściej podczas pisania okazuje co się da i jak zrobić, a czego się nie da.

0
  1. Absolutnie nie! Testy muszą być osobno, inaczej zginiesz w gąszczu dziwnych kodów ;]
  2. Testy są dwojakie: blackbox i whitebox. Blackbox sprawdza czy dla zadanego wejścia dostajemy spodziewane wyjście, czyli sprawdza niejako "czy X działa poprawnie". Whitebox sprawdza czy dla zadanego wejścia wykonują się takie operacje jakie powinny, czyli sprawdza "czy X działa tak jak nam sie wydaje że powinno".
  3. Budując program wersji "release" testów sie tam nie dodaje (chyba ze to oprogramowanie open - source ;) )
  4. jw, są też testy integracyjne (testujące "styki" komponentów)
  5. TDD tak zakłada, ale czy jest to faktycznie takie dobre? Nie jestem przekonany. Ale warto pisać test w tym samym czasie co funkcjonalność. Łatwo wtedy zauważyć jak napisaliśmy brzydki kod, bo ciężko się go potem testuje ;)
0

Dziękuję wszystkim za rady.

Mam tylko pytanie jeszcze co do pkt 1.
Wszystkie testy powinny być w osobnych klasach i według mnie właśnie to pozwala ładnie zapanować nad kodem. Niestety - jeśli mamy n klas to w rezultacie wyjdzie nam 2n klas wraz z testami.
Czy nie spowoduje to rozdęcia kodu?

1

Ja bym poszedł dalej:
będziesz miał nawet więcej kodu! Bo testy black i white box można (i czasem tak się robi) wrzucać do osobnych plików. Zwykle dzieli się to wszystko ładnie na jakieś pakiety/moduły tak ze kod testów nie leży fizycznie tam gdzie kod testowanych klas, tylko w bliźniaczym module z prefixem "tests". Oczywiście że pisanie testów powoduje zwiększenie objętości kodu (co więcej, testy czesto są dłuższe niż kod testowany), no ale coś za coś. Albo masz możliwość puszczenia sobie "regresji" po każdej zmianie w kodzie (i wykrycia od razu że coś się zepsuło) albo piszesz cały program szybciej ale metodą "hope-driven development" ;)

0

Aha, a więc wszystko rozumiem :)
Dziękuję za pomoc. Obawiałem się, że nie rozumiem zasad testowania, i że moje testy byłyby pseudotestami.
Jutro mam właśnie poprawiać swoją klasę i dopisać testy do odpowiednich funkcji, a chcę to zrobić dobrze, by nie uczyć się błędnie :)

Dziękuję jeszcze raz.

0

a ja mam do Was pytanie z innej beczki - sami piszecie testy jednostkowe do swoich klas? Bo jak mi gość od testów odszedł to próbowałem sam napisać (podkreślam do własnych klas) i wyglądało to tak, że kod testu to była praktycznie kopia kodu klasy :/. I nie wyobrażam sobie jakby to inaczej zrobić bo przecież nagle nie wpadnę na genialny całkiem inny algorytm, który będzie robił to samo co ten już zaimplementowany. Ba nikt mi nie da gwarancji, że w szczególnych przypadkach ten nowy nie będzie liczył źle. Jak Wy się na to zapatrujecie?

0

Ja do testów podchodzę tak, by były one wyzwaniem dla każdej funkcji. Każda funkcja ma być przetestowana tak mocno jak to tylko możliwe.
Najłatwiej testować funkcje bez parametrów wejściowych.

Np w moim programie jest takie coś:

 public void CopyCellDataDaysWeek()
        {
            this.ControlDaysWeek.CopyDataGridView();
        }

Funkcja ta kopiuje jedną komórkę danego DataGridView. Nie ma parametrów wejściowych takich jak np "DataGridView DataG", bo owy parametr jest w konstruktorze klasy, dlatego funkcja wie z czego ma kopiować.

I mój test danej funkcji wygląda tak:

        public bool TESTCopyCell()
        {
            try
            {
                this.CopyCellDataDaysWeek();
                return true;
            }
            catch (Exception e)
            {
                this.Log(e);
                return false;
            }
        }

Tak stworzoną funkcję można testować do woli, ale pojedyncze testy to dość mało, więc stworzyłem dodatkowo funkcję:

        public bool TEST(int n)
        {
            Random r = new Random();
            for (int i = 0; i < n; i++)
            {
                this.Data.Rows[r.Next(0, 1000)].Cells[r.Next(0, 1000)].Selected = true;
                if (this.TESTCopyCell() == false) return false;
            }
            return true;
        }

Ładnie w ten sposób widać, czy wszystko poszło gładko. Wystarczy sprawdzić wynik ostatniej metody (true or false) bez zaglądania do dziennika zdarzeń.

0

Dziękuję wszystkim za rady.

Mam tylko pytanie jeszcze co do pkt 1.
Wszystkie testy powinny być w osobnych klasach i według mnie właśnie to pozwala ładnie zapanować nad kodem. Niestety - jeśli mamy n klas to w rezultacie wyjdzie nam 2n klas wraz z testami.
Czy nie spowoduje to rozdęcia kodu?

TDD oczywiście powoduje, że napiszesz znacznie więcej kodu, niż gdybyś olewał testowanie. Ale z drugiej strony:

  • debugowanie w złożonym projekcie jest znacznie bardziej uporczywe i czasochłonne niż otestowanie kodu i wyczajenie błędu w dobrze otestowanym kodzie,
  • dobrze napisane testy jednostkowe, najlepiej w konwencji BDD http://dannorth.net/introducing-bdd/ http://jbehave.org/ są swoistą wykonywalną dokumentacją, wykonywalnymi przypadkami użycia, które są przez cały czas w 100 % zsynchronizowane z kodem - wyobraź sobie nieustanną synchronizację dużej ilości dokumentacji zewnętrznej z kodem, jest to koszmar, do którego bardzo łatwo się zniechęcić,
  • TDD w zasadzie wymusza loose-coupling, modułową budowę programu. To też powoduje,że kodu jest więcej, ale z drugiej strony podmiana lub dodanie jednego alternatywnego klocka (modułu) nie jest wielkim problemem.
  • ogólnie TDD jest do projektów, które ewoluują, a prawie każdy projekt dość mocno ewoluuje. No chyba, że 1) projekt jest malutki, a technologia znana na wylot albo 2) project manager ma szklaną kulę i jest w stanie przewidzieć każdy szczegół na 10 lat wprzód,

1.) Czy kod/y test/ów powinien znajdować się w klasie, którą testuje? Czy może stworzyć osobną klasę np "Testklient"?
Czy może jeszcze inaczej - stworzyć osobną klasę ogólną do testowania np "testujWszystko" i tam kody testów każdej klasy w odpowiednich funkcjach?

Ja stosuję konwencję, która jest stosowana przez Mavena czy NetBeansa: testy umieszczam w osobnym folderze kodu z identyczną strukturą paczek jak w kodzie testowanym. Klasy testujące umieszczam w tych samych pakietach, co klasy testowane (oczywiście jest to osobny katalog jak wynika z poprzedniego zdania). Polecam zajrzeć do dokumentacji Mavena i zapoznać się z jego konwencjami.
Oczywiście test jednostkowy to test jednostkowy, a jednostką jest klasa, więc trzeba zrobić osobny test dla każdej klasy. No i rozdzielić kod testowany od testującego tak jak napisałem przed chwilą.

Kod testu polega na tym, aby ustalić czy dany fragment działa prawidłowo. W związku z tym należy po prostu testować dany fragment na wszystkie możliwe sposoby? Wywoływać funkcje z różnymi parametrami itd?

Kod jest w 100 % przetestowany jeżeli:
a) jest udowodniony analogicznie do dowodów matematycznych,
b) działa dobrze dla każdych możliwych danych na wejściu,

Z tego wynika, iż jeśli np tworzymy funkcję NWD(a, b) dla 32-bitowych intów, to musimy wybrać jedną z dwóch opcji:
a) rozpisać formalny dowód poprawności programu, ale to prawie zawsze jest zbyt kosztowne (w jakimkolwiek sensie),
b) przetestować go dla wszystkich danych wejściowych, czyli przetestować dla 2(32 + 32) = 264 kombinacji parametrów wejściowych. Wtedy będziemy mieli pewność, że dla każdych argumentów działa dobrze. Jednak takie przetestowanie jest niemożliwe ze względów czasowych,

Dlatego zwykle nie testuje się kod w 100 % ale stosuje się różne kryteria, np pokrycie kodu testami, do czego może być przydatne np takie narzędzie jak Cobertura: http://cobertura.sourceforge.net/ Z tym, że nawet jeśli nasz kod pokrywa 100 % kodu testowanego z każdą możliwą kombinacją rozgałęzień w kodzie to i tak w ogólności nie możemy być 100 % pewni, że kod testowany jest poprawny. Jak napisałem wyżej, zwykle musielibyśmy odpalić tak dużą ilość testów, że przetestowanie stałoby się niemożliwe przed kolejnym Wielkim Wybuchem. Ale jeśli kod jest przetestowany wystarczająco profesjonalnie to szansa, że jakieś błędy się jeszcze uchowały jest bardzo mała.

Kod testów powinien zostawać po zakończeniu testu, ponieważ ułatwia to testowanie w następnych etapach projektu. Czy taka sama zasada obowiązuje, gdy projekt jest już ukończony? Czy wtedy nadal kody testów powinny zostać w programie?

Jeśli masz dobrze skonfigurowany projekt (o ile twoje IDE na to pozwala) to przy budowaniu kodu do jego wydania (release) kod testujący w ogóle nie powinien zostać wkompilowany. Dla przykładu w Mavenie jest konwencja (jak napisałem powyżej), że są np takie dwa katalogi jak main/ z kodem produkcyjnym i test/ z kodem testującym. Podczas testowania są wkompilowywane kody z obu folderów, a przy budowaniu produktu końcowego kod testujący nie jest wkompilowywany.

Jest coś takiego jak skończony projekt? Według mnie projekty dzielą się na rozwijane albo porzucone (niewspierane). Jeśli chcesz zgarniać kasę za sprzedaż programu to musisz na bieżąco usuwać błędy, przed którymi nie uchronisz się nawet stosując TDD (ale będzie ich wtedy znacznie mniej), a więc pozbywanie się testów byłoby głupotą. Z drugiej strony, jeśli porzucasz projekt, to porzucasz go w całości.

  1. jw, są też testy integracyjne (testujące "styki" komponentów)

Nie tylko styki komponentów, ale też interakcję ze środowiskiem. Dla przykładu ja teraz robię aplikacje dla Androida i JavyME i testami integracyjnymi nazywa się tam testy, które wymagają odpalenia emulatora do działania. Emulator dostarcza pewnych API związanych ze sprzętem, a więc nazwa test integracyjny jest tutaj w zasadzie słuszna.

Wyczytałem, że kod testujący najlepiej pisać przed kodem właściwym (produkcyjnym). Czy to prawda?

Tak twierdzą ludzie dobrze obeznani w TDD (ja w sumie dopiero zaczynam, na serio to piszę powolutku testy dopiero gdzieś od początku roku). Moim zdaniem taka dyscyplina jest sensowna wtedy, gdy dobrze znasz wykorzystywane technologie i twoja praca nie jest jednym wielkim eksperymentowaniem z API. Jeśli robisz kolejny projekt w jakiejś tam technologii, to mniej więcej wiesz jak wygląda jej użycie, wobec czego napisanie testów powinno być łatwe.

a ja mam do Was pytanie z innej beczki - sami piszecie testy jednostkowe do swoich klas? Bo jak mi gość od testów odszedł to próbowałem sam napisać (podkreślam do własnych klas) i wyglądało to tak, że kod testu to była praktycznie kopia kodu klasy . I nie wyobrażam sobie jakby to inaczej zrobić bo przecież nagle nie wpadnę na genialny całkiem inny algorytm, który będzie robił to samo co ten już zaimplementowany. Ba nikt mi nie da gwarancji, że w szczególnych przypadkach ten nowy nie będzie liczył źle. Jak Wy się na to zapatrujecie?

Jeśli masz jakąś czystą (w sensie matematycznym, czyli bez efektów ubocznych) funkcję to robisz sobie listę kombinacji parametrów wejściowych i oczekiwanych wyników. A więc jeśli np testujesz funkcję podnieśXDoPotęgiA(int x, int a); to danymi wejściowymi mogą być List((1, 2), (2, 3), (3, 2)), a oczekiwanymi wynikami List(1, 8, 9).

No i jeszcze jedna sprawa dość ważna:
W moim odczuciu, jednostką w testach jednostkowych jest klasa, a nie pojedyncza funkcja. Chodzi o testowanie funkcjonalności klasy, a nie testowanie poszczególnych funkcji z osobna. W sumie to taka jest filozofia BDD. Mamy bardziej sprawdzać czy funkcja ma dobrze zaimplementowane funkcjonalności i (to nie zawsze ma miejsce) czy dobrze oddziałuje z otoczeniem, np czy klasa Bankomat nie wywołuje z klasy Bank funkcji, których nie powinna.

Polecam poczytać o BDD, mi to wiele wyjaśniło ;)

0
CiekawskiTestowania napisał(a)

Serdecznie witam.
1.) Czy kod/y test/ów powinien znajdować się w klasie, którą testuje? Czy może stworzyć osobną klasę np "Testklient"?
Czy może jeszcze inaczej - stworzyć osobną klasę ogólną do testowania np "testujWszystko" i tam kody testów każdej klasy w odpowiednich funkcjach?

nie, kod testow to osobny byt i tu takze obowiazuje zasada pojedynczej odpowiedzialnosci - w uproszczeniu jedna klasa testuje jedna klase.

CiekawskiTestowania napisał(a)

2.) Kod testu polega na tym, aby ustalić czy dany fragment działa prawidłowo. W związku z tym należy po prostu testować dany fragment na wszystkie możliwe sposoby? Wywoływać funkcje z różnymi parametrami itd?

to zalezy :P powiniennes testowac kazda sciezke w logice obiektu oraz ustalic krytyczne parametry jak wielkosc danych czy rodzaj danych dla ktorych cos moze sie wysypac

CiekawskiTestowania napisał(a)

3.) Kod testów powinien zostawać po zakończeniu testu, ponieważ ułatwia to testowanie w następnych etapach projektu. Czy taka sama zasada obowiązuje, gdy projekt jest już ukończony? Czy wtedy nadal kody testów powinny zostać w programie?

kod testow to kod testow, i jest to integralna czesc projektu, ktora powinna byc tak samo wersjonowana jak sam kod projektu

CiekawskiTestowania napisał(a)

4.) Jakie rodzaje testów jeszcze istnieją i czym różnią się od testów jednostkowych? Chodzi tu o przykład praktyczny, gdyż teoria jest nieco zamącona.

np:

  • regresyjne (kompatybilnosc wsteczna)
  • wydajnosciowe (load testy i stress testy)
  • penetracyjne (bezpieczenstwo)
  • funkcjonalne (czy logika dziala jak nalezy)
  • akceptacyjne (czy spelnia wymagania)
  • uzytecznosci (czy da sie tego uzywac)
CiekawskiTestowania napisał(a)

5.) Wyczytałem, że kod testujący najlepiej pisać przed kodem właściwym (produkcyjnym). Czy to prawda?

Jedna szkola TDD mowi ze test powinien powstac zanim napiszesz testowany obiekt, imho nawet nie glupie bo wtedy myslisz o interfejsie obiektu zanim od strony uzytkowej zanim zaczniesz cos pisac, natomiast zycie zyciem teoria teorią :P

0

Dziękuję. Wiele mi wyjaśniliście :)

Naszło mnie jeszcze inne pytanie.
Załóżmy, że mamy funkcję, która wykonuje coś z liczbą z danego zakresu. Dla banalnego przykładu chociażby coś takiego:

public void SetAge(int age)
{
 this.MyAge = age;
}

Taki banał, ale chodzi mi o to, czy testować funkcję z parametrami także ujemnymi?
Jako autor programu, wiem, że użytkownik nie będzie miał możliwości przekazania w tej funkcji wartości ujemnej.
Czy będąc pewnym tego, że nic takiego się nie stanie i funkcja zawsze będzie dostawać wartości dodanie w parametrze muszę nadal testować wszelkie warunki?

Może jeszcze inny przykład:

public AddInTable(int Value, int Index, int[] tab)
{
 tab[index] = Value;
}

W takim przypadku wypadałoby przeprowadzać sprawdzanie czy "index" nie jest aby ujemny. Jednak czy na pewno warto dodać specjalnie linijkę if-a nawet jeśli mamy pewność, że index nigdy nie będzie ujemnie przekazany?

W takich sytuacjach wystarczy testować kod z odgórnie przyjętymi zasadami, że ta i ta funkcja na pewno nigdy takich parametrów nie przyjmie?

Moje rozumowanie jest uzasadnione tym, że w żadnych funkcjach, a przynajmniej w większości nie dajemy zawsze zabezpieczenia w stylu:
if (Value == null) to koniec itd.
Skoro nie dajemy takich if-ów to po prostu nalezy trzymać się ustalonych reguł. Czy tak?

1

jako autor programu, powinieneś tam dać po prostu uint.
niestety, używanie typów unsigned jest w C# upierdliwe (często trzeba ręcznie rzutować).

0

Od takich rzeczy w Javie są asercje w C# też to pewnie jest). Generalnie są języki, które wspierają programowanie kontraktowe, ale chyba są niszowe. Myślę, że prędzej stosuje się jakieś frameworki do tego, ale asercje na początek powinny wystarczyć. Zaletą dobrze zaimplementowanych asercji (tzn mówię o implementacji na poziomie platformy dostarczającej tą funkcjonalność) jest to, że asercje można całkowicie wyłączyć (pominąć) przy kompilacji produkcyjnej wersji aplikacji.

0

Serdecznie dziękuję. Faktycznie asercje nadają się idealnie :)

0
CiekawskiTestowania napisał(a)

1.) Czy kod/y test/ów powinien znajdować się w klasie, którą testuje? Czy może stworzyć osobną klasę np "Testklient"?

Każdy testowany moduł aplikacji (project w sensie VS ;)) powinien mieć swój bliźniaczy moduł testujący (np. XYZ.BusinessLogic ma XYZ.Tests.BusinessLogic), każda testowana klasa aplikacji ma bliźniaczą klasę testującą (np. ClientService ma ClientServiceTest).

2.) Kod testu polega na tym, aby ustalić czy dany fragment działa prawidłowo. W związku z tym należy po prostu testować dany fragment na wszystkie możliwe sposoby? Wywoływać funkcje z różnymi parametrami itd?

Na wszystkie możliwe sposoby nie da rady. Testuje się dla jakiejś losowej grupy "normalnych" wartości argumentów oraz dla warunków brzegowych - np. najmniejsza lub największa wartość dla której funkcja powinna zadziałać.

3.) Kod testów powinien zostawać po zakończeniu testu, ponieważ ułatwia to testowanie w następnych etapach projektu. Czy taka sama zasada obowiązuje, gdy projekt jest już ukończony? Czy wtedy nadal kody testów powinny zostać w programie?

Testy siedzą w oddzielnych modułach, więc po co to kasować? Oszczędność miejsca na dysku? ;)

5.) Wyczytałem, że kod testujący najlepiej pisać przed kodem właściwym (produkcyjnym). Czy to prawda?

Człowiek ma ogólnie tendencje do ułatwiania sobie życia, więc pisanie testów po implementacji może się skończyć tym, że napisane zostaną tylko takie testy, które funkcja przechodzi. ;)
Myślę, że dobrze jest pracować w parze - jedna osoba pisze testy, druga kod.

Ale pisanie testów przed kodem nie zawsze jest możliwe, jest to raczej trudne na etapie prototypowania aplikacji lub gdy eksperymentujemy z nowym frameworkiem/technologią - wtedy, gdy nie wiemy jeszcze, co metody mają przyjmować i czego od nich oczekujemy.

Testy pisze się i uruchamia w jakimś frameworku do testowania. Dla C# mogą to być np. nUnit, xUnit bądź MSTest - ten ostatni jest o tyle wygodny, że zintegrowany z Visual Studio, i można sobie wewnątrz klasy kliknąć PPM, wybrać "Create Unit Test", a potem wybrać metody, które chcemy przetestować, a następnie docelowy projekt i wcisnąć "OK". Niby sporo ludzi narzeka, że jest to narzędzie mało funkcjonalne, mi w sumie wystarcza.
I jasnym jest, że to binarki aplikacji są kompilowane, a następnie kopiowane do katalogów testów, żeby dopiero skompilować i odpalić testy. Aplikacja nic nie wie o istnieniu żadnych testów!

W takich sytuacjach wystarczy testować kod z odgórnie przyjętymi zasadami, że ta i ta funkcja na pewno nigdy takich parametrów nie przyjmie?

Moje rozumowanie jest uzasadnione tym, że w żadnych funkcjach, a przynajmniej w większości nie dajemy zawsze zabezpieczenia w stylu:
if (Value == null) to koniec itd.
Skoro nie dajemy takich if-ów to po prostu nalezy trzymać się ustalonych reguł. Czy tak?

To jest kolejny temat filozoficzny. :) A odpowiedź zależy właściwie od ustaleń obowiązujących w projekcie.
Albo stosujemy programowanie defensywne - każda funkcja upewnia się, czy dostała prawidłowe argumenty, albo stosujemy programowanie przez kontrakt - zakładamy, że nie przekazujemy nieprawidłowych wartości, więc się nie zabezpieczamy. Każde z podejść ma swoje zady i walety.

A co jeśli kod już istnieje i nie ma do niego testów? Albo nie jesteśmy pewni, czy nasze testy nie dają pełnego pokrycia?
Możemy użyć takiego miłego narzędzia, które nazywa się Pex (http://research.microsoft.com/en-us/projects/pex/). Analizuje on kod metody, a następnie wywołuje ją z różnymi danymi wejściowymi i sprawdza wyniki, dzięki czemu pozwala na wykrycie błędów w działaniu metody oraz wyjątków przez nią rzucanych. Na podstawie wyników jego działania można jednym kliknięciem dodać brakujące asercje lub wygenerować kod testujący ze 100% pokryciem.

0

Jesli ktos chce zobaczy jak wygadaja profesjonalne testy polecam obejrzec pare odcinkow sumer of hibernate: http://www.summerofnhibernate.com/
Mniej wiecej tak moim zdaniem powiny wygladac unit testy:)

Co do rodzajow sa jeszcze: testy longevity - system idzie dlugo pod srednim stabilnym obciazeniem, expert testy (doswiadczeni testerzy robia co moga by wywalic aplikacje, to jest bardzo skuteczne uzupelnienie), testy akceptacyjne (srawdza sie czy system jest zgodny z tym co chcial klient), testy uzytecznosci (zgodnosc z wymaganiami to jedno, ale musi to byc jeszcze uzywalne), alfa i beta testy (wychodzi wersja alfa albo beta i ludzie testuja, np. Microsoft i Windows 8), smoke testy - podlacza sie urzadzenie, albo wlacza system, jak bedzie dym to fail. Sanity testy - sprawdzanie podstawowych funkcjoalnosci i jeszcze pewnie by sie pare rzeczy znalazlo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1