Synteza aplikacji biznesowych

2014/15

Instrukcja laboratoryjna cz.3

Testy funkcjonalne (aplikacja TeamCity)

Prowadzący: Tomasz Goluch

Wersja: 3.0

Testowanie aplikacji z bazą danych

Większość współczesnych aplikacji korzysta z bazy danych. Ich testowanie nie należy do

najłatwiejszych z wielu powodów. M.in. problemem może być przygotowanie danych

testowych w bazie danych oraz zmiana jej zawartości podczas przeprowadzania testów (np.

dodanie/zmodyfikowanie rekordu). Celem ćwiczenia jest stworzenie testów dla aplikacji z

wykorzystaniem rzeczywistej bazy danych. Dodatkowe zadanie polega na rozszerzeniu

istniejącej aplikacji o określoną funkcjonalność oraz automatyzację napisanych testów w

oparciu o aplikację TeamCity.

Solucja

Została przygotowana solucja z dwoma projektami (do pobrania ze strony przedmiotu).

Pierwszy projekt jest biblioteką, która zawiera kod produkcyjny, drugi projekt zawiera test

(MSTest). Projekty są poprawnie skonfigurowane oraz zawierają wszystkie niezbędne

biblioteki (Entity Framework 5.0).

Aplikacja skonfigurowana jest tak, że używa bazy danych w folderze D:\Temp\blog-test.mdf,

dlatego też należy stworzyć ten folder, lub zmienić konfigurację w projekcie z testami

(app.config).

Aplikacja korzysta z narzędzia Entity Framework i zawiera klasę z modelem – Post, kontekst

bazy danych („Code First”) – BlogContext oraz klasę repozytorium – PostRepository, która

stanowi warstwę abstrakcji nad klasą kontekstu (wzorzec Repozytorium).

W pierwszej kolejności należy zbudować całą solucję i uruchomić istniejący test za pomocą

narzędzia wbudowanego w Visual Studio 2010 klikając PPM na nazwie testu i wybierając

odpowiednią opcję.

Wynik testu jest negatywny ponieważ metoda zwróciła 0 rekordów, a oczekiwana liczba to 1.

Można sprawić, żeby test dał wynik pozytywny poprzez dodanie rekordu do tabeli w bazie

danych. Aby to zrobić należy otworzyć plik bazy za pomocą Server Explorera w narzędziu

Visual Studio 2010 (Tools -> Connect to Database a następnie wpisać dane jak poniżej).

Jeśli plik z bazą nie znajduje się w folderze c:\Temp należy się upewnić, że projekt z testami

został przebudowany oraz testy zostały uruchomione (ponieważ baza tworzy się podczas

wywołania testu).

Następnie należy dodać rekord do tabeli Posts (wybierając opcję Show Table Data z menu

kontekstowego tabeli) - dane nie są istotne tylko sam fakt istnienia rekordu. NASTĘPNIE

NALEŻY ZAMKNĄĆ POŁĄCZENIE Z BAZĄ DANYCH (w Server Exlorere). Po dodaniu rekordów

należy ponownie uruchomić testy tak jak poprzednio. Jeśli wszystko zostało wykonane

poprawnie należy zgłosić ten fakt prowadzącemu.

Przygotowanie danych w ten sposób jest bardzo niewydajne i wymusza aby wszystkie testy

bazowały na jednym (niezmiennym) stanie bazy. Dlatego też dużo lepszym rozwiązaniem jest

przygotowanie danych w środowisku testowym. Aby to zrobić należy dodać podany poniżej

kod na końcu części arrange w teście.

// -- prepare data in db context.Posts.ToList().ForEach(x => context.Posts.Remove(x)); context.Posts.Add(new Post { Author = "test", Content = "test, test, test..." }); context.SaveChanges();

Następnie należy uruchomić ponownie test. Wynik powinien być również pozytywny. Należy

zgłosić ten fakt prowadzącemu.

Ten sposób również jest mało wydajny, ponieważ kod ten musi być kopiowany do każdego

testu. Można kod przygotowujący dane wynieść do metody z atrybutem [TestInitialize], ale

wtedy również musimy w ten sam sposób przygotowywać wszystkie inne klasy testowe.

Do projektu została dołączona biblioteka, która umieszczona jest w folderze

packages/DbTestHelpers/ TDD.DbTestHelpers.dll.

Aby skorzystać z biblioteki należy dodać klasę bazową DbBaseTest<BlogFixtures> dla klasy

RepositoryTests, która znajduje się w namespace’ie TDD.DbTestHelpers.Core. Klasę

BlogFixtures należy stworzyć w projekcie z testami i powinna ona wyglądać następująco:

public class BlogFixtures : YamlDbFixture<BlogContext, BlogFixturesModel> { public BlogFixtures() { SetYamlFiles("posts.yml"); } }

Należy uzupełnić brakujące usingi, natomiast klasa BlogFixtures powinna wyglądać

następująco:

public class BlogFixturesModel { public FixtureTable<Post> Posts { get; set; } }

Jeśli wszystko zostało wykonane poprawnie projekt powinien się budować. Ostatnim

krokiem jest dodanie danych, w tym celu należy stworzyć folder Fixtures oraz dodać do

niego plik posts.yml:

Posts: test-post: Author: test Content: test, test, test...

Należy zwrócić uwagę na białe znaki. Nie należy uważyć tabulatorów w plikach yaml lecz

dwóch spacji. Biblioteka jest skonfigurowana poprawnie, należy usunąć kod dodany do testu,

który miał przygotowywać bazę danych oraz uruchomić test. Jeśli wynik jest poprawny

należy fakt ten zgłosić prowadzącemu.

Aby zobaczyć jak działa biblioteka można dodać kolejny post i zmienić test tak, aby

weryfikował istnienie dwóch postów.

Zadania do wykonania:

1) Rozszerzyć funkcjonalność repozytorium o możliwość dodawania postów

2) Walidację danych (pola wymagane)

3) (dodatkowe – domowe) Dodanie drugiej tabeli (np. komentarze) oraz napisanie

obsługi dodawania komentarza i wyświetlenia komentarzy dla konkretnego postu.

Uwaga: aby używać relacji pomiędzy tabelami w entity framework należy:

1) Rozszerzyć BlogFixturesModel o kolejną właściwość

2) Użyć albo drugiego pliku dla drugiej tabeli (SetFixtureFiles przyjmuje kolekcję nazw

plików) lub dopisać dane dla drugiej kolekcji w już istniejącym stosując tą samą

konwencję

3) Używać przypisanych (lokalnie! nie w bazie) kluczy głównych i obcych

Np.

posts: test-post: Id: 1 Author: test Content: test, test, test... comments: test-post-comment: PostId: 1 Content: ha ha ha

Konfiguracja TeamCity

Wstęp

Aplikacja TeamCity należy do grupy aplikacji ciągłej integracji (Continuous Integration). Ciągła

integracja to praktyka programistyczna, która polega na częstym (ciągłym) budowaniu

i testowaniu (integrowaniu) wytwarzanego oprogramowania za pomocą odpowiednich

narzędzi. Cykl wytwarzania oprogramowania przedstawiony jest poniżej.

Trigger – wyzwalacz, który rozpoczyna proces integracji; najczęściej stosowanym

wyzwalaczem jest przesłanie kodu źródłowego do systemu kontroli wersji (source

control system);

Compile/Build – pierwszym krokiem jest zbudowanie aplikacji z kodu źródłowego; na

tym etapie wykrywane są błędy w strukturze kodu, można również ustawić dodatkowe

opcje kompilacji (w środowisku developerskim wyłączone ze względu np. na wydłużenie

czasu kompilacji), które wyświetlają dodatkowe informacje, jak np. błędy w widokach;

Deploy – następnym krokiem jest publikacja aplikacji na środowisko testów (dla aplikacji

webowej jest to serwer np. IIS);

Trigger (by change)

Compile

Deploy Test/Analyse

Report

Test/Analyse – najważniejszym krokiem jest uruchomienie testów oraz różnych aplikacji

analizujących kod, np. pod kątem zgodności z przyjętymi standardami, i/lub pokrycie

testami;

Report – ostatnim krokiem jest stworzenie raportu z przebiegu całego procesu;

w przypadku, kiedy nie zostały spełnione postawione warunki, informacja o błędzie

przesyłana jest, np. za pomocą wiadomości e-mail, do odpowiednich osób.

Aplikacja TeamCity posiada mechanizmy umożliwiające wykonanie wszystkich wymienionych

kroków. Wspiera wiele języków programowania (m.in. Java, C#, PHP, Ruby) oraz różnych

narzędzi służących do publikowania aplikacji (m.in. Ant, NAnt, Rake, MSBuild, MSDeploy).

Instalacja

Aby zainstalować aplikację TeamCity należy:

1. Ściągnąć najnowszą wersję narzędzia TeamCity dla odpowiedniego systemu

operacyjnego ze strony http://www.jetbrains.com/teamcity/download/index.html.

2. Zainstalować aplikację (wymagane uprawnienia administratora) z domyślnymi

ustawieniami.

3. Jako docelowy port wybrać inny port niż port 80 (np. 8080 albo 9080 – zainstalowane

w laboratorium) .

4. Zapisać domyślne ustawienia dla Build Agenta.

5. Zarówno usługę TeamCity jak i Build Agenta uruchomić jako użytkownik SYSTEM.

6. Uruchomić obydwie usługi zaznaczając odpowiednie pola.

7. Otworzyć stronę zaznaczając pole na ostatnim kroku.

Konfiguracja

Po uruchomieniu strony aplikacji należy stworzyć nową bazę oraz zaakceptować warunki

umowy. Następnie należy stworzyć użytkownika (należy zapamiętać hasło). Adres e-mail jest

ważny, ponieważ powiadomienia będą wysyłane na podany adres. Po stworzeniu

użytkownika powinna być widoczna strona informująca o braku projektów.

Aby skonfigurować nowy projekt należy:

1. Kliknąć przycisk „Create project”.

2. Podać nazwę i opis projektu (np. TeamCity test; opis nie jest wymagany).

3. Kliknąć przycisk „add a build configuration”.

4. Podać nazwę konfiguracji (np. „Continuous integration”); pozostałe ustawienia należy

zostawić bez zmian. Kliknąć przycisk „VCS settings”.

5. Kliknąć przycisk „Create and attach new VCS root”

6. Wybrać „Subversion” jako typ systemu kontroli wersji.

7. Uzupełnić pola jak na poniższym rysunku. Pozostałe pola zostawić bez zmian.

8. Po przekierowaniu na stronę konfiguracji systemu kontroli wersji kliknąć przycisk

„Add build step”.

9. Wybrać typ runnera „Visual Studio (sln)”. Nazwać krok „Build” i wypełnić pola jak na

poniższym rysunku, pozostałe pozostawić bez zmian.

10. Uruchomić agenta klikają na przycisk „Run” w prawym górnym rogu aplikacji.

11. Przejść na stronę projektu (lewy górny róg aplikacji).

12. Kliknąć na przycisk „Edit Project Settings”, a następnie „Edit” przy kolumnie „Build

Steps”.

13. Przejść na zakładkę „Build Step: Visual Studio (sln)” i kliknąć przycisk „Add build step”

14. Wybrać typ „NUnit” i uzupełnić pola jak na poniższym rysunku i zapisać zmiany.

15. Ponownie uruchomić agenta przyciskiem „Run” i przejść na zakładkę z projektami.

Jeśli cały proces przebiegł pomyślnie powinien być widoczny ekran z podsumowaniem

ostatniego (udanego) builda. Po kliknięciu na build można ujrzeć szczegóły wraz z opisem

poszczególnych uruchomionych testów.

Zadanie do wykonania:

1) Umieścić wcześniej napisany kod wraz z testami funkcjonalnymi w repozytorium Git i

skonfigurować aplikację TeamCity do ich obsługi.