inżynieria oprogramowania testy jednostkowe dokumentacja

J.NAWROCKI, M. ANTCZAK, W. FROHMBERG, K. KOLANOWSKI, J. POCHMARA,
S. WĄSIK, T. ŻOK
INŻYNIERIA OPROGRAMOWANIA
TESTY JEDNOSTKOWE
DOKUMENTACJA TECHNICZNA
UWAGA!!! Pobieramy z moodle’a archiwum CuTestPowerPack.zip i rozpakowujemy je na pulpicie.
WYKORZYSTYWANE NARZĘDZIA
ŚRODOWISKO PROGRAMISTYCZNE CODE::BLOCKS
Dobrze znane środowisko wykorzystywane na laboratoriach.
DOKUMENTACJA TECHNICZNA (INSTALACJA BIBLIOTEKI DOXYGEN)
Tworzenie dokumentacji jest bardzo czasochłonnych i długotrwałym procesem, który jest często pomijany, lub
traktowany jako „dodatkową pracę”. Wystarczy sobie wyobrazić, że pracujemy w dużej firmie
programistycznej, w której następują wymiany zespołów pracujących nad projektami. Wtedy, gdy nie
posiadamy żadnej dokumentacji technicznej dla powstałych już w projekcie modułów i jeszcze w dodatku nie
jest wykorzystywany ten sam standard kodowania przez wszystkich programistów, a co gorsza trzeba dokonać
pewną małą modyfikację w module projektu, a człowiek, który się u nas jeszcze niedawno tym zajmował już nie
pracuje wtedy pojawia się problem. W celu rozwiązania tego problemu został zaproponowany pewien
mechanizm, który polega na automatycznym generowaniu dokumentacji technicznej dla projektu, którego
funkcje w plikach nagłówkowych modułów są odpowiednio skomentowane za pomocą określonych „tagów”
np.:
UWAGA!!! Przed rozpoczęciem instalacji na laboratorium sprawdzamy czy narzędzie nie jest już dostępne w
lokalizacji „C:\Software\doxygen”.
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
W katalogu "CuTestPowerPack\install\generowanie dokumentacji\doxygen1.4.6" znajduje się plik „doxygen1.4.6-setup.exe”, który jest
instalatorem biblioteki wykorzystywanej do generowania dokumentacji
technicznej. Uruchamiamy plik instalatora.
1. Na ekranie powitalnym naciskamy przycisk „Next”.
2. Zatwierdzamy licencję.
3. Definiujemy i zatwierdzamy ścieżkę dostępu („C:\Software\doxygen”).
4. Wybieramy i zatwierdzamy rodzaj instalacji (preferujemy „Full”).
5. Decydujemy o utworzeniu skrótów w Menu Start.
6. Rozpoczynamy instalację za pomocą przycisku „Install”.
7. Potwierdzamy zapoznanie się z informacjami konfiguracyjnymi prezentowanymi przez system.
8. Kończymy instalację za pomocą przycisku „Finish”.
TESTOWANIE JEDNOSTKOWE (CUNIT, CUTEST)
Testy jednostkowe to rozbudowanie mechanizmów asercji, raportowania i automatyzacji testów.
Asercja jest wymuszeniem zachowania określonego warunku podczas pracy symulowanego systemu (np.:
przyjmowanie przez dany sygnał określonego stanu – wartości). Testy jednostkowe to moduły testujące
(jednostki testowe), które można uruchamiać w izolacji od pozostałych. Raporty to kontrola jakości
wykonywanej pracy.
Złożoność projektów wymusza automatyzację testów i odciążenie projektanta od wykonywania powtarzalnych
czynności.
Grupa xUnit jest grupą narzędzi automatyzujących proces testowania jednostkowego. Narzędzia te szeroko
polecają twórcy metodyki XP (eXtreme Programming). Historycznie pierwszym narzędziem był napisany przez
Kenta Backa Sunit (dla języka Smalltalk). Podejście xUnit szybko zyskało popularność. Obecnie istnieją liczne
jego implementacje dla większości znanych języków programowania (JUnit, CPPUnit, PHPUnit, PerlUnit, itd.).
Większość wersji zawiera prostą aplikację okienkową, która pozwala zarządzać procesem testowania (wybór
przypadków testowych, wyświetlanie postępu, prezentacja ostatecznych wyników).
Podejście xUnit dostarcza ram do implementowania przypadków testowych w tym samym języku
programowania, w którym tworzymy rozwijany system. Jednocześnie w prosty sposób możemy grupować i
uruchamiać testy. Poniżej przedstawiamy sposób pracy z narzędziem.
Dla każdego projektu, którego moduły chcemy przetestować budujemy tzw., „TestSuite”, czyli oddzielny moduł
grupujący wszystkie testy związane z rozważanym projektem. Stworzenie pojedynczego testu polega na
umieszczeniu w tym module nowej funkcji. Jej nazwę rozpoczynamy frazą „test”, na przykład „testCreation”,
„testConnection”, itd. Pracując z prostszymi językami programowania, takimi jak C, konieczne jest ręczne
dodawanie testów do zestawów. Następnie uruchamiamy proces testowania. Ważne jest aby poszczególne
testy były wykonywane niezależnie.
Zaletami narzędzi xUnit są:
-
implementacje dla wszystkich popularnych języków programowania,
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
-
niezależność od wykorzystywanego systemu operacyjnego,
-
rozpowszechnianie na zasadzie OpenSource,
-
ścisłe powiązanie testów z kodem budowanego systemu.
Wadą jest tu brak gotowych bibliotek funkcji, które ułatwiłyby budowanie testów oraz trudności z testowaniem
graficznych interfejsów użytkownika.
WIELOMODUŁOWOŚĆ
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
PROJEKT
1.
2.
Uruchamiamy środowisko Code::Blocks.
Otwieramy projekt CUExample, który będziemy wykorzystywali podczas zajęć (znajduje się w katalogu
…\Desktop\CuTestPowerPack\examples\CUExample) z wykorzystaniem File->Open....
3.
Po poprawnie wykonanym imporcie powinien się pojawić ekran podobny do zawartego poniżej:
4.
Po zbudowaniu i uruchomieniu aplikacji powinno się pojawić okno podobne do zawartego poniżej:
5.
Katalog CuTest oraz plik nagłówkowy CuTest.h są skojarzone z prostą biblioteką pozwalającą na
tworzenie testów jednostkowych dla języka C. Są one potrzebne w projekcie ale praktycznie nie będą
modyfikowane. Jedynie w pliku AllTests.c będą dodawane pakiety testów, które zostaną przez nas
napisane.
Funkcja main() zawiera tylko wywołanie funkcji bibliotecznej RunAllTests() pozwalającej na
uruchomienie wszystkich testów dla tworzonego projektu. Aktualnie projekt jest pusty, więc nie
zawiera on żadnych testów.
Naszym zadaniem jest utworzenie modułu prostego kalkulatora, który będzie wyznaczał sumę, różnice
i iloczyn dwóch liczb całkowitych. Każdy moduł, jak wiemy, składa się z dwóch plików: nagłówkowego
np.: Calc.h, który zawiera interfejs (zbiór nagłówków dostępnych funkcji) oraz implementacji Calc.c,
który zawiera implementację funkcji, które zostały zdefiniowane w interfejsie tworzonego modułu.
Tworzymy plik nagłówkowy Calc.c wybierając File->New->File… Następnie wybieramy C/C++ Header i
klikamy w przycisk Go w górnej, prawej części okna. Pojawi się okno informacyjne na którym
wybieramy
przycisk
Next.
Następnie
podajemy
ścieżkę
dostępu
(...\Desktop\CuTestPowerPack\examples\CUExample\include\Calc.h) oraz nazwę nowego pliku
nagłówkowego (patrz niżej).
6.
7.
8.
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
9.
Po kliknięciu przycisku Save zaznaczamy pola wyboru dotyczące konfiguracji Debug i Release, dla
których chcemy aby nasz plik nagłówkowy tworzonego modułu był dostępny. Ostatecznie wybieramy
przycisk Finish.
10. W efekcie powinien się pojawić nowy plik Calc.h w katalogu include naszego projektu.
11. Stworzony przed momentem plik nagłówkowy uzupełniamy deklaracją nagłówka funkcji wyznaczającej
sumę dwóch liczb całkowitych, które są przekazywane jako parametry wejściowe. Po uaktualnieniu
pliku nagłówkowego powinien on mieć następującą postać:
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
12. W kolejnym kroku tworzymy plik z implementacją Calc.c naszego modułu korzystając z podobnych jak
w przypadku pliku nagłówkowego. Różnica polega na tym, że wybieramy typ pliku jako C/C++ source
zamiast C/C++ header oraz ścieżka dostępu dla nowego pliku powinna mieć postać
...\Desktop\CUnitPowerPack\examples\CUExample\Calc\Calc.c.
13. W katalogu Calc tworzymy plik z implementacją Calc.c.
14. Po kliknięciu przycisku Save ponownie zaznaczamy pola wyboru dotyczące konfiguracji Debug i Release
oraz ostatecznie wybieramy przycisk Finish.
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
15. Stworzony przed momentem plik nagłówkowy uzupełniamy implementacją funkcji wyznaczającej
sumę dwóch liczb całkowitych. Każda implementacja modułu musi wiedzieć jakie funkcje ma
implementować, a więc importuje wcześniej stworzony interfejs z wykorzystaniem dyrektywy #include
i ścieżki względnej do plik nagłówkowego.
16. W kolejnym kroku modyfikowany jest główny plik naszego projektu main.c, w taki sposób aby mogli
zaimportować i przetestować funkcjonalność stworzonego modułu Calc.
17. Po poprawnym uruchomieniu (F9) i wpisaniu jako wejściu liczb całkowitych 1, 2 powinniśmy uzyskać
wynik podobny do przedstawionego poniżej:
18. Aby wielokrotnie przy każdej zmianie funkcjonalności systemu nie musieć testować wszystkich funkcji
od nowa wprowadzone zostały testy jednostkowe, które pozwalają na automatyzację procesu
testowania. W kolejnym kroku utworzyć należy plik CalcSuite.c, który będzie zbiorem testów
związanych implementowanym aktualnie modułem. Stosujemy taki sam sposób tworzenia nowego
pliku w projekcie jak w przypadku implementacji modułu Calc.c. Ścieżka w której powinien się znaleźć
nowy plik to ...\Desktop\CuTestPowerPack\examples\CUExample\Calc\CalcSuite.c. W efekcie
powinniśmy uzyskać:
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
19. Uzupełniamy implementację tworzonego pakietu testów CalsSuite.c.
20. Tworzymy prostą funkcję testCalcAddFalse(CuTest *tc) testującą wykonanie funkcji add(int a, int b) z
modułu Calc pozwalającej na wyznaczenie sumy dwóch liczb całkowitych dla przykładowych wartości
wejściowych a=1, b=2, sprawdzamy czy wynik funkcji będzie równy 4 (przykład negatywny).
21. Jest już stworzony pakiet CalcSuite z jednym testem naszego modułu. Mimo wszystko gdy uruchomimy
program wciąż system nam wyświetla, że nie widzi żadnych testów (ich liczba jest równa 0). Musimy
poinformować bibliotekę CuTest o tym, że utworzyliśmy nowy pakiet testów poprzez uzupełnienie
funkcji void RunAllTests(void) w sposób zaprezentowany na poniższym rysunku:
22. Komentujemy w ciele funkcji main() pliku main.c wszystkie linie z wyjątkiem RunAllTests(void).
23. Po uruchomieniu aplikacji uzyskujemy poniższy wynik:
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
24. Modyfikujemy test w taki sposób, aby zakończył się powodzeniem. W efekcie na ekranie powinno się
wyświetlić okno podobne do zaprezentowanego poniżej:
25. Dodawanie specjalnych tagów do pliku nagłówkowego modułu Calc.h pozwalających na automatyczne
wygenerowanie dokumentacji technicznej w formacie html.
26. W celu wygenerowania dokumentacji należy uruchomić „Doxywizard”, który znajduje się w katalogu,
w którym został zainstalowany Doxygen.
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.
27. Uruchamiamy „Wizard...” i definiujemy ustawienia konfiguracyjne dla projektu (poniższe zrzuty
ekranowe obrazują konfigurację dla przykładowego projektu „CUExample”).
28. Zapisujemy plik konfiguracyjny (domyślnie „Doxyfile”) w katalogu projektu. Poprawne zapisanie pliku
konfiguracyjnego zostanie zgłoszone przez system zmianą statusu na „saved”.
29. Ustawiamy w polu edycyjnym „Working directory” ścieżkę do katalogu projektu.
30. Uruchamiamy generowanie dokumentacji korzystając z przycisku „Start”.
31. Jeżeli powyższe kroki zostały wykonane poprawnie, wówczas w podkatalogu „doc” projektu powinna
pojawić się wygenerowana dokumentacja techniczna.
32. Uzupełnij program w taki sposób, aby implementowany moduł udostępniał funkcjonalność
pozwalającą na wyznaczanie dodatkowo różnicy i iloczynu dwóch liczb całkowitych. Dla każdej
funkcji modułu powinny zostać utworzone co najmniej dwie funkcje testowe i stosowne komentarze
pozwalające na wygenerowane dokumentacji technicznej systemu.
(*) gwiazdką oznaczone są zadania, które nie są realizowane na ćwiczeniach i są przeznaczone do
wykonania jako zadania domowe.