160 likes | 297 Views
Wprowadzenie do automatyzacji testów funkcjonalnych aplikacji webowych z Visual Studio 2010. Maciej Gawin. Agenda. 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
E N D
Wprowadzenie do automatyzacji testów funkcjonalnych aplikacji webowych z Visual Studio 2010 Maciej Gawin
Agenda • 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
Automatyzacja testów UI – zanim zaczniemy... • 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??)
Automatyzacja testów UI – zanim zaczniemy... c.d. • 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)
Automatyzacja testów UI – zanim zaczniemy... c.d. • 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.
Visual Studio 2010 jako narzędzie testerskie • 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
Visual Studio 2010 jako narzędzie testerskie c.d. • 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
Visual Studio 2010 jako narzędzie testerskie c.d. • 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#)
Coded UI - podstawy • 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 - podstawy • 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)
Coded UI - podstawy • Typowy workflow przy pracy z testami CodedUI • Utwórz nowy projekt testowy w VS • Dodaj nowy element -> Test CodedUI • Nagraj procedurę testową używając CodedUI test buildera (zostanie ona „przetłumaczona” na akcję UIMap) • Zrefaktoruj wygenerowaną akcję używając edytora CodedUI • Dodaj asercje używając test buildera CodedUI • (Jeśli trzeba, dodaj własny kod do obsługi niestandardowych zdarzeń lub kontrolek) • Uruchamiaj testy • ... • Gdy aplikacja zostanie zmieniona, zrefaktoruj testy poprzez ponowne nagranie akcji i zmiany asercji • Uruchamiaj testy
Coded UI – przykład na żywo • 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)
Coded UI – przykład na żywo • 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!!!
Coded UI – subiektywna ocena • 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)
Coded UI – subiektywna ocena • ... 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)