Coded UI Test - tworzenie testów UI przy pomocy Visual Studio Ultimate

Poszukując sposobów automatycznego testowania aplikacji natrafiłem na ciekawą funkcjonalność Visual Studio 2010 Ultimate. Mianowicie w tej wersji naszego ulubionego IDE znalazło się miejsce na nowy typ testów - Coded UI Test. Coded UI Test jest to automatyczny test UI, który tworzymy poprzez nagrywanie akcji jakie wykonujemy w naszej aplikacji. Nie musimy pisać ani jednej linijki kodu żeby przetestować jakąś funkcjonalność naszego programu. Jedyne co musimy zrobić jest to przejście przez wszystkie niezbędne kroki w naszej aplikacji, tak aby zweryfikować naszą funkcjonalność. W celu stworzenia Coded UI Test musimy po pierwsze zaopatrzyć się w wersję Ultimate Visual Studio 2010. Z tego co wiem, niestety niższe wersje nie mają funkcjonalności automatycznego testowania. Następnie musimy stworzyć nowy Test Project. W tym celu z menu File wybieramy New a następnie Project. W oknie, które się pokaże, w drzewie po lewej stronie wybieramy Test, a następnie w prawej części okna Test Project
.
Mając stworzony projekt testowy dodajemy do niego nowy Coded UI Test. W Solution Explore-rze klikamy PPM na projekt testowy, a następnie z menu contextowego wybieramy Coded UI Test.
. W oknie, które się pojawi wybieramy Record actions,edit UI map or add assertion lub gdy mamy już gotowe testy możemy wybrać opcję nr 2. Po wybraniu pierwszej opcji okno Visual Studio zostanie zminimalizowane, a w prawym dolnym rogu pulpitu ukaże się następujące okienko.
. Służy ono do nagrywania testu. Naciskając czerwony przycisk rozpoczynamy proces nagrywania testu. W moim przypadku będę testować aplikację, którą testowałem również w poprzednim poście. Wykonuje zatem czynności mające na celu sprawdzenie funkcjonalności dodawania liczb. Po kliknięciu na textbox-a pojawia się nad nim dymek,że dana akcja jest nagrywana.

Po "wyklikaniu" całej ścieżki mającej sprawdzić funkcjonalność klikamy przycisk "Generate code"" (ten najbardziej z prawej strony). Następnie w okienku, które się pojawi

podajemy nazwę naszego testu. Po kliknięciu OK, Visual Studio wygeneruje nam kod odpowiedzialny za nasz test.

W celu odpalenia naszego testu z menu Test wybieramy Run, a następnie Tests in Current Context. Visual Studio przejdzie teraz wszystkie kroki, które zostały nagrane w teście. Ok, niby wszystko ładnie pięknie, ale tak naprawdę nic nie sprawdziliśmy. Jedyne co zrobiliśmy to wykonaliśmy pewne operacje na naszej aplikacji, jednakże nie zweryfikowaliśmy danych otrzymanych w wyniku operacji dodaj. W celu dodania warunku sprawdzającego do naszego testu, musimy dodać tzw. asercję. Aby to zrobić klikamy PPM na wolne pole edytora, pod funkcją this.UIMap.RecordedMethod1() (ta funkcja została wygenerowana podczas nagrywania testu). Następnie z menu contextowego wybieramy

Otwiera nam się znane już wcześniej okienko nagrywania testu. Jednakże tym razem naciśnijmy przycisk celownika i przeciągnijmy go na textbox-a, w którym ma pojawić się wynik dodawania

Nasz textbox zostanie obramowany, natomiast w prawym dolnym rogu pulpitu pojawi się nowe okno pokazujące propertisy naszego przycisku. Wybierzmy właściwość Text ,a następnie naciśnijmy przycisk Add Assertion

W oknie, które się pojawi możemy wybrać warunek, który musi spełnić dana właściwość (w tym przypadku Text), aby test przeszedł. Ustawmy tam wartość np. 3. Następnie klikamy OK oraz nadajemy nazwę naszej assercji.Po wykonaniu tych czynności w kodzie naszego pojawi się dodatkowa linijka

Teraz za każdym razem gdy odpalimy test na samym jego końcu będzie sprawdzana nasza assercja. W przypadku gdy wartość właściwości Text nie będzie równa 3 nasz test nie przejdzie.

Read more »

Scrum i Team Foundation Server cz.4 - Tworzymy projekt

W poprzednich wpisach opisałem ogólne zasady metodyki Scrum, przedstawiłem sposób instalacji i konfiguracji - TFS. W tym wpisie pokażę podstawowe zasady jak połączyć teorię z praktyką. Podobnie jak w poprzednich wpisach bazował będę na Team Foundation Server 11 DP, konieczne również będzie Visual Studio 11 DP.

Załóżmy, że chcemy wytworzyć grę komputerową - One Card Master. Gra ta będzie niczym innym niż uproszczoną wersją gry w wojnę. Każdy z graczy otrzymuje po jednej karcie - wygrywa osoba, która ma największą kartę.

 

1. Połączenie z TFS

Uruchommy Visual Studio. Posiada ona specjalną sekcję odpowiedzialną za elementy zarządzania projektem. Jeżeli nie jesteśmy połączeni widzimy tylko jedną opcję - "Connect to Team Foundation Server", po połączeniu pojawi się ich więcej. Wybieramy opcję połączenia.

Ukaże nam się okno wyboru serwera, z którym chcemy się połączyć. Ponieważ jest to nasze pierwsze połączenie lista wyboru jest pusta.

Naciskamy przycisk "Servers" by zdefiniować połączenie. 

Ponieważ chcemy dodać nowe połączenie naciskamy przycisk "Add"

W pole na górze wpisujemy nazwę (lub adres) naszego serwera - w moim przypadku jest to "win-mpmq6e2dm0c". Naciskamy "OK" i w oknie wyboru serwera "Close".

Teraz w oknie wyboru serwera w liście rozwijalnej powinniśmy zobaczyć nasz serwer. Wybieramy go i naciskamy przycisk "Connect". Zostaniemy poproszeni o dane autoryzacyjne - podajmy dane administratora serwera.


2. Utworzenie projektu


Jesteśmy już połączeni z serwerem, możemy przejść zatem do utworzenia naszego projektu.
Do zarządzania projektem służy "Team Explorer". Można go włączyć poprzez Menu=>View=>Team Explorer.

Aby utworzyć nowy projekt naciskamy "Create New Team Project".

Wpisujemy nazwę naszego projektu i ewentualnie opis i kilkamy "Next".

 

Team Foundation Server pozwala na definiowanie i używanie szablonów projektów. W ich obrębie można m.in. definiować typy zadań, przepływy między nimi. TFS dostarcza od razu kilka z nich oraz pozwala na pobranie innych z MSDN. Ponieważ chcemy prowadzić nasz projekt przy pomocy metodyki Scrum, wybieramy szablon "Microsoft Visual Studio Scrum 2.0 - Preview 1" i naciskamy przycisk "Finish". Nastąpi teraz proces konfiguracji nowego projektu, po jego pomyślnym zakończeniu naciskamy przycisk "Close".
Po dodaniu projektu Visual Studio automatycznie połączy nas z nim - widoczne to będzie od razu po wyglądzie menu Team Explorera.

3. Utworzenie zespołu

Podobnie jak w filmach typu "Parszywa dwunastka", czy "7 wspaniałych" pierwszym krokiem w konfiguracji naszego projektu jest utworzenie zespołu. 

Konta w TFS powiązane są z kontami systemowymi. Możemy tego dokonać poprzez systemowe okno zarządzania komputerem (dostępne przez Start => All Programs => Administrative Tools=> Computer Management).

Dodajemy kilku "Janów Kowalskich" w celach testowych i zamykamy okno.


TFS przy konfiguracji serwera tworzy bardzo przydatną rzecz jaką jest strona pozwalająca na zdalny do niego dostęp. Pozwala ona w wygodny sposób zarządzać zadaniami, użytkownikami i procesami projektu. Dalszej konfiguracji będziemy dokonywać przy jego pomocy. Aby się do niej dostać naciskamy "Web Access" w Team Explorerze.

Domyślnie została utworzona grupa projektowa dla naszego projektu. Aby dodać do niej inne osoby klikamy na "My Team" oraz w kolejnym ekranie przycisk "Administration" (znajdujący się w prawym górnym rogu).

Wchodzimy do sekcji "members", w liście rozwijalnej "Actions" wybieramy "Manage Team Membership".

Aby dodać użytkownika naciskamy przycisk "add members". 

W pole wpisujemy użytkownika, którego chcemy dodać, naciskamy "check name", a następnie "Save Changes".


Należy dodać jeszcze naszą grupę projektową do grupy uprawnień pozwalającej na dostęp do projektu i działanie na nim. Dokonujemy tego naciskając link z  nazwą naszego projektu znajdujący się w górnym menu strony.

Przechodzimy do zakładki "project groups" i wybieramy grupę uczestników projektu - "contributors".

W sekcji "Group membership" naciskamy przycisk "manage membership". W znanym nam już oknie wybieramy "add tfs group" i z listy wybieralnej bierzemy grupę [One Card Master]\My Team. Dzięki temu, każdy nowy użytkownik, którego dołączymy do zespołu projektowego automatycznie nabędzie stosowne uprawnienia.


4. Przygotowania do pierwszego sprintu


Mając wybrany i utworzony zespół możemy przystąpić do planowania projektu. Zgodnie z metodyką Scrum będziemy go dzielić na Sprinty oraz pomocniczo grupować je w Release'y. Grupowanie takie jest przydatne z tego względu, że pozwala na lepszą motywację, grupowanie faz oddawania projektu klientowi (np. jeden release to utworzenie konkretnego modułu). Tak jak wspomniałem we wcześniejszym artykule długość Sprintu być w przedziale 2-4 tygodnie (z tym, że każdy Sprint powinien trwać tyle samo). Liczba sprintów w Releasie też jest kwestią ustaleń.
Dostęp do Sprintów oraz Release'ów znajduje się w sekcji Iterations.

Jak widać zostały utworzone 4 releasy, każdy po 6 sprintów. Do celów testowych tak dużo nie jest nam potrzebne. Usuńmy tak elementy by został nam jeden Release składający się z 4 Sprintów.

Każdy ze sprintów będzie trwał 2 tygodnie. Dobrą zasadą jest od razu zaplanowanie dat startu i końca kolejnych sprintów. Efekt powinie wyglądać podobnie jak na poniższym screenie:

Zwykle planując projekt dzielimy zadania na grupy np. wg biznesowych zasad (np. modułami) lub programistycznych kategorii (np. baza danych, serwer aplikacji, klient). Takie grupowanie można też dokonać w TFS poprzez zakładkę "areas".

Ja utworzyłem 3 zgodnie z planowanymi modułami:
- Administracja
- Ekran Gry
- Panel użytkownika
Oczywiście grupy można zagnieżdżać jeszcze głębiej, nie musi to być płaska struktura jak w tym przykładzie.


5. Planowanie zadań


Zadania planujemy poprzez zakładkę "backlog" projektu. Wychodzimy z administracji (przez link "Exit administration) i przechodzimy do niej.

W TFS przyjęto, że zadania grupowane są w historie użytkownika (Product Backlog Item, Bug) opisujące konkretny przypadek do zrealizowania. Gdy uznamy, że chcemy, żeby była realizowana powinniśmy przypisać do niej co najmniej jedno zadanie. Jest to odzwierciedlenie standardowego procesu tworzenia systemów informatycznych. Jako programiści zwykle dostajemy opis zadania w postaci przepływu biznesowego. Musimy wtedy zwykle dokonać zmian na bazie, dodać metody na serwisie i oprogramować klienta. 


Historię użytkownika (PBI) dodajemy poprzez przycisk "Add".

Posiada ono następujące główne elementy:
- Assigned To - osoba odpowiedzialna za realizację historii użytkownika
- Status - aktualny status zadania
- Reason - powód dokonania akcji
- Effort - wysiłek, który należy wykonać aby skończyć to PBI. Wyrażone to jest w story pointach (jaki czas ma jeden story point jest kwestią ustalenia w projekcie)
- Business Value - jest to wartość, jaką wniesie ta historia użytkownika do projektu
- Area - grupa zadań, do którego zalicza się PBI


Od razu przy dodawaniu historii użytkownika można zdefiniować zadania do niego. Można tego dokonać przechodząc do zakładki "Tasks" i naciśnięcie przycisku "New".

Zadanie posiada m.in. pola:
- Assigned To - użytkownik, do którego zostało przypisane zadanie
- State - aktualny status zadania
- Reason - powód dokonywanej akcji
- Blocked - czy zadanie jest zablokowane (nie powinno być aktualnie robione)
- Description - opis
- Remaining Work - effor pozostały do zakończenia zadania
- Backlog Priority - priorytet zadania
- Activity - rodzaj czynności wykonywanej w zadaniu (np. Development, Documentation)
- Area - grupa zadań, do których zalicza się ten task


Po dodaniu PBI i zadań w widoku rejestru produktu (backlog) pojawi się nowy wpis.


6. Realizacja sprintu


Zarządzanie realizacją sprintu można zobaczyć w zakładce "board".

Na tym ekranie widać wszystkie historie użytkownika oraz ich zadania w obrębie aktualnego sprintu. 
Tablica (dashboard) jest klasycznym Scrumowym widokiem. Zadania podzielone są na trzy grupy:
- To Do - nie rozpoczęte,
- In Progress - w trakcie robienia,
- Done - skończone.
W prostocie tego widoku tkwi jego siła. Widać na nim dokładnie, które zadania zostały już rozpoczęte, kto się czym zajmuje aktualnie oraz co zostało skończone. 
Zadania można w prosty sposób poprzez przeciągnięcie przenosić pomiędzy jednym statusem a drugim. Poprzez podwójne kliknięcie wchodzić do ich edycji. W prawym górnym rogu widoczny jest również Burndown Chart - czyli wykres postępu prac (o nim postaram się napisać w osobnym wpisie).


7. Dodanie projektu do kontroli wersji


Jedyną rzeczą, która pozostała nam do zrobienia by można było zacząć realizować projekt jest dodanie plików do kontroli wersji.


Wracamy do Visual Studio i Team Explorera. Naciskamy przycisk Source Control Explorer.

Wybieramy nasz projekt i naciskamy "Map to Local Folder". Wybierzemy to aby określić, w którym miejscu na naszym lokalnym komputerze będą przechowywane pliki projektu. Po dokonaniu mapowania, naciskamy przycisk "New Folder" aby dodać folder o nazwie "src" (z kodami źródłowymi).

Poprzez przycisk "New Project" w oknie "Start Page" dodajemy nowy projekt z lokacją w zmapowanym folderze. Zaznaczamy dodatkowo "Add to source control".

Wszystkie foldery i pliki, które utworzyliśmy do tego momentu znajdują się tylko lokalnie na naszym dysku. Aby zmiany zostały wrzucone na serwer należy przejść do Team Explorera, nacisnąć "My Work", a następnie "Check In".

Zobaczymy listę wszystkich naszych zmian. Dobrym zwyczajem jest podanie komentarza przy check inie. Po naciśnięciu przycisku Check In zmiany zostaną wrzucone na serwer.

Podstawowa konfiguracja TFS do pracy z projektem została dokonana. W kolejnych wpisach postaram się przybliżyć każdy z tych kroków dokładniej.

Read more »