Zpo-3-wyk-Slajd7: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 4: Linia 4:




Klasa testująca w Junit 3.x ma określoną strukturę:
Klasa testująca w JUnit 3.x ma określoną strukturę:
* konstruktor przyjmuje parametr będący nazwą przypadku testowego; zwykle nie ma on żadnego znaczenia i można go pominąć.
* konstruktor przyjmuje parametr będący nazwą przypadku testowego; zwykle nie ma on żadnego znaczenia i można go pominąć.
* metoda ''setUp'' ''()'' służy do inicjacji każdego przypadku testowego; jest wykonywana przed każdym z nich i zwykle służy do stworzenia obiektu testowanego i innych obiektów wymaganych do uruchomienia go. Metoda ta jest dziedziczona po klasie TestCase
* metoda ''setUp'' ''()'' służy do inicjacji każdego przypadku testowego; jest wykonywana przed każdym z nich i zwykle służy do stworzenia obiektu testowanego i innych obiektów wymaganych do uruchomienia go. Metoda ta jest dziedziczona po klasie TestCase

Aktualna wersja na dzień 10:54, 17 paź 2006

Struktura klasy testującej

Struktura klasy testującej


Klasa testująca w JUnit 3.x ma określoną strukturę:

  • konstruktor przyjmuje parametr będący nazwą przypadku testowego; zwykle nie ma on żadnego znaczenia i można go pominąć.
  • metoda setUp () służy do inicjacji każdego przypadku testowego; jest wykonywana przed każdym z nich i zwykle służy do stworzenia obiektu testowanego i innych obiektów wymaganych do uruchomienia go. Metoda ta jest dziedziczona po klasie TestCase
  • przypadki testowe są implementowane w pojedynczych metod zawartych w klasie testującej. Muszą one spełniać konwencję przyjętą w JUnit 3.x: nie przyjmować parametrów, nie zwracać wartości oraz mieć nazwę zaczynającą się od przedrostka 'test' (inne metody nie są rozpoznawane jako przypadki testowe). Wykonanie każdego przypadku testowego jest poprzedzone wywołaniem metody setUp () i zakończone wywołaniem metody tearDown ()
  • metoda tearDown () jest komplementarna w stosunku do metody setUp (), tzn. służy do przywrócenia stanu sprzed wykonania testu. Jeżeli setUp () jedynie tworzyła obiekty, wówczas implementacja tearDown () jest zbędna; ma ona znaczenie tylko jeżeli przypadek testowy zaalokował zasób, który powinien być zwolniony np. połączenie sieciowe lub do bazy danych etc. Wówczas metoda ta powinna ten zasób zwolnić


<< Poprzedni slajd | Spis treści | Następny slajd >>