INŻYNIERIA OPROGRAMOWANIA TESTY JEDNOSTKOWE DOKUMENTACJA TECHNICZNA

Transkrypt

1 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.

2 W katalogu "CuTestPowerPack\install\generowanie dokumentacji\doxygen1.4.6" znajduje się plik doxygen 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,

3 - 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ŚĆ

4 PROJEKT 1. Uruchamiamy środowisko Code::Blocks. 2. Otwieramy projekt CUExample, który będziemy wykorzystywali podczas zajęć (znajduje się w katalogu \Desktop\CuTestPowerPack\examples\CUExample) z wykorzystaniem File->Open 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. 6. 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. 7. 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. 8. 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).

5 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ć:

6 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.

7 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ć:

8 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:

9 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.

10 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.