Instrukcja laboratoryjna z testów funkcjonalnych (aplikacja TeamCity)

Instrukcja laboratoryjna z testów funkcjonalnych (aplikacja TeamCity)

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
(by change)
Report
Test/Analyse

Compile
Deploy
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);

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.