2 Systemy Odporne na Błędy

Transkrypt

2 Systemy Odporne na Błędy
Systemy Odporne na Błędy 2015/2016
Instrukcja
laboratoryjna
2
1/2
Systemy Odporne na Błędy
Testy jednostkowe w Javie
Przygotowali: dr inż. Grzegorz Łukawski, mgr inż. Daniel Kaczmarski
1) Testy jednostkowe
Testy jednostkowe są prostym i relatywnie tanim sposobem pozwalającym szybciej tworzyć
niezawodny kod. Są ważnym elementem projektu i przyczyniają się do sukcesu każdego programisty.
Test jednostkowy jest fragmentem kodu sprawdzającym działanie pewnego niewielkiego, dokładnie
określonego obszaru funkcjonalności testowanego kodu. Zadaniem testów jednostkowych jest
udowodnienie, że kod działa zgodnie z założeniem programisty.
2) Asercje JUnit
Asercje są podstawowymi elementami, z których buduje się testy jednostkowe. Szkielet Junit
dostarcza różne formy asercji.
AssertEquals – ta forma asercji jest najczęściej używana. Parametr expected jest spodziewanym
wynikiem działania testowanej metody, a actual reprezentuje wartość będącą wynikiem rzeczywistym,
uzyskanym podczas testu. Parametr message jest opcjonalny i może zawierać komunikat wyświetlany,
gdy asercja nie powiedzie się.
assertEquals([String message], exepected, actual)
AssertNull – poniższe asercje umożliwiają sprawdzenie, czy obiekt jest równy bądź różny od null. W
przeciwnym razie asercja zawodzi. Parametr message jest opcjonalny.
assertNull([String message], java.lang.Object object)
assertNotNull([String message], java.lang.Object object)
AssertSame – sprawdza, czy expected i actual reprezentują ten sam obiekt. W przeciwnym razie
asercja zawodzi. Parametr message jest opcjonalny. Natomiast assertNotSame sprawdza, czy
expected i actual reprezentują różne obiekty.
assertSame([String message], exepected, actual)
assertNotSame([String message], exepected, actual)
AssertTrue – sprawdza, czy podany warunek logiczny jest prawdziwy. W przeciwnym razie asercja
zawodzi. Parametr message jest opcjonalny.
assertTrue([String message], boolean condition)
Systemy Odporne na Błędy 2015/2016
2/2
fail – od razu powoduje niepomyślne zakończenie testu, wyświetlając opcjonalny komunikat message.
Często używana w celu zaznaczenia sekcji kodu, które nie powinny zostać osiągnięte.
fail([String message])
3) Przykład
Poniższy kod testujący, który przedstawia minimalny szkielet umożliwiający wykonanie testów
jednostkowych:
import junit.framework.*;
public class TestSimple extends TestCase {
public TestSimple(String name) {
super(name);
}
public void testAdd() {
assertEquals(2,1+1);
}
}
4) Zadanie do wykonania
Stwórz klasę reprezentującą stos. Umożliwiającą odkładanie obiektów typu String na stosiei
zdejmowanie ich ze stosu. Program powinien być wyposażony w mechanizm odporności na błędy:
– w przypadku stosu, który nie był jeszcze używany, metoda isEmpty() powinna zwracać wartość true, a
metody top() i pop() generować wyjątek,
– rozpocznij od pustego stosu, odłóż na stosie łańcuch tekstowy, wywołując metodę push(). Wywołaj
kilkakrotnie metodę top() i sprawdź, czy za każdym razem zwraca właściwy łańcuch. Wywołaj
metodę isEmpty() i sprawdź, czy zwróciła wartość logiczną false,
– usuń łańcuch ze stosu, wywołując metodę pop(), i sprawdź czy zwróciła ten sam łańcuch, który
wcześniej umieściłeś na stosie(tu nie wystarczy użyć samej asercji assertEquals(), musimy wywołać
asercję assertSame(), aby sprawdzić czy jest to ten sam obiekt). Wywołanie metody isEmpty()
powinno zwrócić wartość logiczną true. Wywołując ponownie metodę pop() i sprawdź czy
wygenerowała tym razem wyjątek,
– wykonaj powyższy test, odkładając tym razem wiele elementów na stosie. Sprawdź czy wywołania
metody pop() zwracają odpowiednie elementy we właściwej kolejności (ostatni element odłożony na
stosie powinien zostać zwrócony jako pierwszy),
– odłóż na stosie wartość null i zdejmij ją ze stosu za pomocą metody pop(). Sprawdź czy rzeczywiście
otrzymałeś wartość nul,
– Sprawdź czy po wyrzuceniu wyjątku stos nadal działa poprawnie.

Podobne dokumenty