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.