Transcript Wprowadzenie do CodedUI

Maciej Gawin







Automatyzacja testów UI – zanim zaczniemy...
Visual Studio 2010 jako narzędzie testerskie
Coded UI - podstawy
Coded UI – jak napisać test?
Coded UI – przykład na żywo
Coded UI – subiektywna ocena
Q&A

Automatyzować czy nie automatyzować? ...
◦ Nie ma złotej reguły (temat na osobne spotkanie)
 Kiedy automatyzować? Kiedy tylko sie da!!!
 Testy automatyczne? Nie, dziękuję. Nie mamy obecnie pieniędzy do
zmarnowania.
 Zajmiemy się tym, jak tylko zostanie nam trochę czasu...
◦ Decyzję o automatyzacji należy podjąć bardzo rozważnie,
biorąc po uwagę:




Typ testów wykonywanych w projekcie
Oczekiwany cykl życia rozwijanego produktu (przewidywane ROI)
Złożoność rozwijanej aplikacji i kosztowność testów manualnych
Delivery Model zastosowany w projekcie (czy będzie czas na
automatyzację testów??)
◦ Decyzję o automatyzacji należy podjąć bardzo rozważnie, biorąc
po uwagę:
 Continuous Integration – czy da się zastosować w projekcie?
 Wrażliwość i złożoność danych testowych
Automatyzacja testów wymaga konsekwencji i
zrozumienia przez cały zespół projektowy
(Developerzy, Testerzy, Management)

Wybór właściwego narzędzia testowego
◦ Podejmij przymyślaną decyzję w oparciu o:
 Doświadczenie, kompetencje i preferencje zespołu testerskiego (czy są
to bardziej programiści czy testerzy manualni?)
 Dostępność narzędzi (zależy ona od zastosowanych technologii,
budżetu, wewnętrznych ograniczeń organizacji)
 Oczekiwane tempo rozwoju produktu oraz potrzebę przyszłego
utrzymania testów
 Łatwość integracji ze środowiskiem developerskim (IDE, kontrola wersji,
narzędzia CI, itd.)
Pamiętaj, raz podjęta decyzja o wyborze
narzędzia jest zazwyczaj bardzo trudna do
zmiany.

Przed erą VS 2010
◦ Dostępne jedynie testy Webtest dla aplikacji webowych (VS 2005,
VS 2008)
 Praca bezpośrednio na poziomie strumienia HTTP
 Ubogie możliwości testowania funkcjonalności
 Brak testów operujących bezpośrednio na przeglądarce
 Brak obsługi javascript
◦
◦
◦
◦
Słaba utrzymywalność wygenerowanych testów
Brak kontroli programatycznej nad testami
Uboga funkcjonalność zarządzania testami i ich wykonaniem
Porównywalne konkurencyjne narzędzia: Apache jMeter

Co nam daje VS 2010?
◦ Testy Coded UI
 Pełne możliwości testów funkcjonalnych UI dla aplikacji Web/WPF 3.5+/
Silverlight 4 wewnątrz przeglądarki
 Funkcjonalność Record&Playback dla aplikacji webowych i
desktopowych
 Kontrolę nad testami z poziomu kodu
 Pełną integrację z projektem (analogiczną do unit testów) i źródłami
danych
◦ Testy wydajnościowe oparte o strumień HTTP nadal dostępne
◦ Bogate możliwości zarządzania testami
◦ Porównywalne konkurencyjne narzędzia: TestComplete, Selenium,
HP QTP, Ranorex, Telerik WebAii, White

Co jest potrzebne, aby zacząć pracę z Coded UI?
◦ Visual Studio Premium lub Ultimate
 Z Feature Pack 2 (subskrypcja MSDN wymagana), aby aktywować edytor
graficzny, wsparcie dla Firefox, wsparcie dla Silverlight 4
◦ Testowalną aplikację (np. webową lub opartą o WPF/WinForms)
◦ Podstawowe umiejętności programistyczne (np. C#)

Struktura projektu testowego Coded UI
◦
◦
◦
◦
◦
Standardowy Test Project – taki sam jak dla Unit Testów
Klasa testowa z dekoracją [CodedUITest]
Metody testowe z dekoracjami [TestMethod], [TestInitialize], itd.
Dostęp do obiektu TestContext (analogicznie jak dla innych projektów testowych)
Akcje i asercje na elementach UI wywoływane za pomocą metod udostępnianych
przez instancje klasy UIMap

Coded UI Test Map (UIMap)
◦ Struktura reprezentująca mapę elementów interfejsu użytkownika aplikacji
◦ Zawiera informacje o kontrolkach podlegających testowi i zdefiniowanych akcjach na
nich operujących
◦ Składa sie z klas częściowych i struktury xml
◦ Może być stworzona za pomocą Coded UI buildera (nagrana)
◦ Może być zaimportowana na podstawie istniejącego nagrania testów manualnych z
Team Foundation Server
◦ Może być edytowana za pomocą graficznego edytora
◦ Akcje i obiekty są udostępnione poprzez metody i właściwości dostępne
bezpośrednio w metodach testowych
◦ Kod UIMap jest autogenerowany i nie powinien byc ręcznie modyfikowany (za
wyjątkiem klasy częsciowej w pliku UIMap.cs)
◦ Osobny obiekt UIMap zazwyczaj reprezentuje oddzielny fragment aplikacji (np.
widok, strone, okno dialogowe)

Typowy workflow przy pracy z testami CodedUI
1. Utwórz nowy projekt testowy w VS
2. Dodaj nowy element -> Test CodedUI
3. Nagraj procedurę testową używając CodedUI test buildera (zostanie ona
„przetłumaczona” na akcję UIMap)
4. Zrefaktoruj wygenerowaną akcję używając edytora CodedUI
5. Dodaj asercje używając test buildera CodedUI
6. (Jeśli trzeba, dodaj własny kod do obsługi niestandardowych zdarzeń lub kontrolek)
7. Uruchamiaj testy
8. ...
9. Gdy aplikacja zostanie zmieniona, zrefaktoruj testy poprzez ponowne nagranie akcji
i zmiany asercji
10. Uruchamiaj testy

Dobre praktyki, aby tworzyć solidne i
łatwoutrzymywalne testy automatyczne z CodedUI
Używaj CodedUI test buildera kiedy tylko to możliwe
Modyfikuj akcje UIMap za pomoca edytora graficznego lub ponownego nagrywania
Nie modyfikuj plików autogenerowanych
Jeśli jesteś zmuszony tworzyć własny kod akcji/asercji, modyfikuj jedynie klasę
cześciową <UIMap>.cs
◦ Dziel scenariusze testowe w sekwencje logicznie rozdzielonych i prostych akcji UIMap
◦ Każda akcja UIMap powinna manipulować elementami tylko jednego widoku UI
◦ Twórz krotkie akcje UIMap (max. ~10 kroków)
◦
◦
◦
◦

Dobre praktyki, aby tworzyć solidne i
łatwoutrzymywalne testy automatyczne z CodedUI
◦ Twórz oddzielny obiekt UIMap dla osobnych fragmentów aplikacji
◦ Używaj konsekwentnie spójnej konwencji nazewniczej dla elementów testów (metod,
asercji)
◦ Współpracuj z developerami, aby kontrolki UI były zawsze opatrzone znaczącym i
spójnym z konwencją Id
◦ Twórz przejrzyste metody testowe, oddzielaj powtarzającą się logikę inicjalizacji od
kodu scenariusza testowego
◦ Uruchamiaj testy automatyczne tak często, jak tylko możliwe (najlepiej jako element
automatycznych buildów)
◦ Nie zwlekaj z aktualizowaniem testów, automatyzacja wymaga konsekwencji od
całego zespołu developerskiego!!!

Plusy
◦
◦
◦
◦
◦
◦
◦
◦
◦
Stabilne, przyjazne użytkownikowi i łatwe w zastosowaniu narzędzie
Pełna integracja z projektami VS
Stosunkowo łatwa utrzymywalność nagrywanych testów
Dobry kompromis pomiędzy podejściem Record&Playback i programatyczną kontrolą
testów
Skuteczne mechanizmy synchronizacji akcji w czasie (czasy oczekiwań, kontrola
ładowania stron)
Wspólny framework testowy dla WPF/Silverlight i Web
Bardzo rozbudowane możliwości raportowania i schedulowania testów
Możliwość rozszerzania funkcjonalności przez implementacje customowych pluginów
Dla projektów rozwijanych w oparciu o .Net, CodedUI stanowi bardzo silną
konkurencję wobec liderów rynku narzędzi do automatyzacji (Selenium,
TestComplete, QTP)

... oraz minusy
◦ Cena


Wymagana co najmniej wersja VS Premium lub Ultimate
Edycja VS Test Professional nie zawiera CodedUI
◦ Brak wsparcia innych przeglądarek (pomimo, że ponoć Firefox 3.6/4.0 jest wspierany,
nie wydaje się by można opierać o to narzędzie testy cross-browser)
◦ Istotne funkcjonalności dostępne są jedynie po instalacji Feature Packa
◦ Brak wsparcia dla testów interfejsu MS Office bez tworzenia customizowanego
pluginu (co mogłoby dać przewagę nad konkurencją)
◦ Niepełna obsługa wywołań asynchronicznych (automatyzacja AJAXa wymaga w wielu
przypadkach dodatkowego wysiłku i zaprogramowania często skomplikowanej
obslugi zdarzeń)
◦ Brak łatwej integracji z narzędziami CI (brak supportu dla Nunit/xUnit – pełna
instancja Visual Studio niezbędna na serwerze buildów ze względu na wbudowane
biblioteki)
◦ Narzędzie w praktyce dedykowane dla jednej technologii (problematyczne w
przypadku organizacji prowadzących projekty w zróżnicowanych technologiach –
uniwersalne cross-platformowe narzędzia są preferowane)