Istnieje wiele świetnych książek na temat automatyzacji testów, a w szczególności na temat najlepszych praktyk w tym zakresie. Jednak żadna z tych książek nie jest uniwersalna. Jak to ktoś kiedyś powiedział: „Te ‚najlepsze praktyki’ są zawsze kontekstowe: nawet coś tak powszechnego jak oddychanie może mieć katastrofalne skutki, jeśli kontekstem będzie swobodne nurkowanie…”.
Większość książek, które przeczytałem do tej pory na temat automatyzacji testów, skierowana jest w dużej mierze do deweloperów i skupia się głównie na testach jednostkowych lub pisanych przez deweloperów testach kompleksowych. Inne książki, które albo przeczytałem, albo o których słyszałem, poświęcone są konkretnej technologii automatyzacji testów, konkretnej metodyce, lub po prostu są już zbyt nieaktualne. Choć ogólnie zgadzam się z tym, że idea, zgodnie z którą to deweloperzy piszą testy, może być w wielu sytuacjach bardzo efektywna, to w rzeczywistości nie pasuje ona do wszystkich organizacji na wszystkich etapach. Co więcej, automatyzacja testów jest narzędziem, które służy i ma wpływ niemal na wszystkich interesariuszy organizacji tworzącej oprogramowanie, wliczając w to testerów, menedżerów produktu, architektów oprogramowania, ludzi z zespołów DevOps oraz menedżerów projektów, a nie tylko deweloperów. Ponieważ każda organizacja i każdy projekt oprogramowania jest inny, próba dostosowania technik, praktyk i narzędzi, które nie pasują do potrzeb lub umiejętności danego zespołu, może doprowadzić do niepowodzenia projektu automatyzacji testów, a w niektórych przypadkach nawet do upadku całego projektu oprogramowania.
Książka ta ma na celu zaprezentowanie szerokiego poglądu na temat automatyzacji testów, aby umożliwić czytelnikowi podejmowanie mądrych decyzji dotyczących jego konkretnego przypadku – biorąc przy tym pod uwagę jego ograniczenia i korzyści, jakie chce on uzyskać dzięki automatyzacji testów – ale również dostarczenie szczegółowych i praktycznych porad w zakresie efektywnej budowy automatyzacji testów, a przynajmniej dla większości przypadków.
kto powinien przeczytać tę książkę?
Ponieważ automatyzacja testów wywiera wpływ na prawie wszystkich interesariuszy organizacji tworzącej oprogramowanie i w tej książce staramy się omówić prawie każdy aspekt automatyzacji testów, jest ona przeznaczona dla każdego, kto jest zaangażowany w proces tworzenia oprogramowania i chce dowiedzieć się, w jaki sposób można uzyskać więcej korzyści z automatyzacji testów. Do grona tych osób zaliczyć można: menedżerów zespołów zapewniania jakości, menedżerów zespołów deweloperów, deweloperów, testerów, architektów, menedżerów produktu (nazywanych również analitykami biznesowymi, analitykami systemu lub jeszcze inaczej), ludzi z zespołów DevOps itd. No i oczywiście deweloperów automatyzacji testów, których głównym zadaniem jest tworzenie testów automatycznych… Znaczna część tej książki nie ma zbyt technicznego charakteru i skierowana jest do szerszego odbiorcy, jednak rozdziały od 11 do 14 są bardzo techniczne i skierowane do osób, które piszą kod i są dobrze zaznajomione z programowaniem obiektowym –w szczególności mam tu na myśli profesjonalnych deweloperów automatyzacji testów. Kod w tej części napisany został w języku C#, ale same koncepcje i pojęcia można z łatwością przenieść na inny obiektowy język programowania. Ponieważ języki C# i Java są do siebie podobne, programiści Java nie powinni mieć większego problemu ze zrozumieniem tego kodu. Jestem jednak przekonany, że również programiści innych języków będą w stanie łatwo go zrozumieć, a przynajmniej jego główne idee.
W szczególności mam nadzieję, że książkę tę przeczyta wielu menedżerów zespołów deweloperów i zapewniania jakości, ponieważ zwykle to oni mają największy wpływ na kształtowanie metodyki i procesów pracy w swojej organizacji, z którymi to automatyzacja testów powinna się integrować i wspomagać ich rozwój. Ponadto książka ta zawiera wskazówki i techniki przydatne dla osób niebędących menedżerami, pozwalające im usprawniać stosowane w organizacji metodyki i procesy pracy nawet bez żadnej formalnej władzy.
Jak zorganizowana jest ta książka?
Gdy po raz pierwszy usiadłem do pisania tej książki, starałem się myśleć o jej ogólnej strukturze, ale zorientowałem się, że będzie to bardzo trudne zadanie, ponieważ wygląda na to, że prawie każdy temat jest powiązany z wieloma innymi tematami. W tamtym czasie nie mogłem znaleźć przejrzystego i logicznego sposobu podzielenia jej treści na ogólne części, tak więc napisałem „gruntowny spis” tematów, które chciałem w tej książce omówić i po prostu zacząłem je pisać, przelewając swoją wiedzę bezpośrednio na papier (a mówiąc bardziej precyzyjnie, na klawiaturę…). Naturalnie rozpocząłem od najprostszych i najbardziej ogólnych rzeczy, a następnie stopniowo rozbudowywałem je o kolejne, bardziej zaawansowane i szczegółowe rozdziały. Ponieważ tematy te są ze sobą ściśle powiązane, często pisałem fragmenty odwołujące się do tematu, którego jeszcze nie napisałem, a przy bardziej zaawansowanych tematach odwoływałem się do wcześniejszych rozdziałów. Tak więc ostatecznie, niczym w dobrym projekcie Agile (a skoro już mowa o odwołaniach do innych rozdziałów, to zobacz rozdział 1, zawierający więcej informacji na temat metodyki
Agile), ogólna struktura tej książki zaczęła się stopniowo ujawniać. W pewnym momencie zdałem sobie sprawę, że książka przybrała dosyć logiczną strukturę złożoną z dwóch części: pierwsza część odpowiada bardziej na ogólne pytania typu „dlaczego” oraz „co”, zaś druga część odpowiada na bardziej szczegółowe i techniczne pytania typu „jak”.
Ogólnie zachęcam czytelników do przeczytania całej książki od początku do końca. Ponieważ jednak książka ta skierowana jest do szerokiego grona odbiorców o różnych problemach, umiejętnościach, zainteresowaniach, potrzebach itd., można również skupić się na lekturze wyłącznie konkretnych rozdziałów, przeglądając lub nawet pomijając pozostałe. Można przy tym też skakać w przód i w tył do innych rozdziałów wspominanych w aktualnie czytanym fragmencie, aby w razie potrzeby uzupełnić swoją wiedzę. Wreszcie warto zawsze trzymać tę książkę w pobliżu, aby skorzystać z niej później, gdy zastosowanie automatyzacji testów w organizacji wystarczająco dojrzeje i zacznie stawiać czoło nowym wyzwaniom.
Oto przegląd poszczególnych części i rozdziałów tej książki:
Część I: „Dlaczego” oraz „Co”
Ta część omawia temat automatyzacji testów pod kątem wielu różnych aspektów, ale w bardziej „ogólny” sposób. Ta część książki jest niezbędna dla tych, którzy nie mają dużego doświadczenia z automatyzacją testów i chcą się dowiedzieć, jak wpasowuje się ona w szeroki obraz tworzenia oprogramowania, oraz od czego można zacząć. Zawarte w niej rozdziały pomogą nam również zrozumieć to, czego możemy, a także czego nie powinniśmy oczekiwać od automatyzacji testów. Jest to szczególnie istotne dla menedżerów zespołów deweloperów i zapewniania jakości, ponieważ omawiają one takie aspekty jak struktura biznesu, procesy pracy, architektura itd. Ta część książki pomoże nam przy podejmowaniu wielu decyzji, jakie nas czekają (czego wiele osób nie bierze nawet pod uwagę!) i pokaże nam, jaki wpływ może mieć każda z nich. Nawet jeśli nie jesteśmy menedżerami i uważamy, że nie mamy żadnego wpływu na te rzeczy, powinniśmy przeczytać rozdziały z tej części, aby zrozumieć ograniczenia i zalety w naszej obecnej sytuacji, a także być w stanie lepiej komunikować je naszym menedżerom.
Jeśli mamy już doświadczenie z automatyzacją testów, to ta pierwsza część pomoże nam poszerzyć w tym temacie nasze horyzonty i pokaże nam opcje oraz konsekwencje związane z decyzjami, które wcześniej podjęliśmy w mniej świadomy sposób.
Część II: „Jak”
Po ogólnym zapoznaniu się z dziedziną automatyzacji testów, czas zakasać rękawy i zacząć pisać testy wraz z wymaganą infrastrukturą. Po napisaniu kilku testów wyjaśniamy, w jaki sposób możemy zrobić krok na przód i najbardziej efektywnie wykorzystać automatyzację testów w cyklu tworzenia oprogramowania.
Od strony merytorycznej rozdziały w tej części można podzielić na dwie grupy (przy czym podział ten nie jest nigdzie jawnie podany, z wyjątkiem tego miejsca): rozdziały od 9 do 14 pisane są jako praktyczny samouczek, w ramach którego projektujemy i tworzymy system automatyzacji testów wraz z kilkoma testami (z użyciem narzędzia Selenium) dla istniejącego projektu open source, zaś rozdziały od 15 do 19 stanowią przewodnik po wykorzystywaniu automatyzacji testów w najbardziej efektywny sposób, pokazując przy tym, jak wyciągnąć z niej maksimum korzyści.
Większość rozdziałów z tej pierwszej grupy ma bardzo techniczny charakter, w przeciwieństwie do rozdziałów drugiej grupy. Z tego powodu pierwsza grupa rozdziałów jest bardziej odpowiednia dla deweloperów, a w szczególności dla deweloperów automatyzacji testów posiadających umiejętności w zakresie programowania obiektowego, natomiast druga grupa rozdziałów może być użyteczna dla każdego. Doświadczonych deweloperów zachęcam do podążania za samouczkiem krok po kroku i wykonywania wszystkich kroków samodzielnie, aby mogli oni doświadczyć ich w lepszym stopniu. Osoby, które nie potrafią programować, powinny przejrzeć te bardziej techniczne rozdziały w celu zapoznania się z głównymi koncepcjami, które są w nich zawarte, nawet jeśli osoby te nie zamierzają implementować ich w swoim własnym projekcie.
Oto kompletny opis rozdziałów:
Część I:
• Rozdział 1: Wartość automatyzacji testów – w tym rozdziale wyjaśniono, dlaczego automatyzacja testów jest potrzebna i jakie są jej krótko- i długoterminowe korzyści.
• Rozdział 2: Od testowania ręcznego do automatycznego – ten rozdział zawiera omówienie różnic pomiędzy testowaniem ręcznym i automatycznym oraz początek nakreślenia realistycznych oczekiwań dotyczących automatyzacji testów, ponieważ znacząco różni się ona od zwyczajnie szybszych testów manualnych.
• Rozdział 3: Ludzie i narzędzia – w tym rozdziale wyjaśniono, kto powinien pisać testy i infrastrukturę automatyzacji, oraz jakie są konsekwencje stosowania alternatywnych rozwiązań. Dodatkowo omówiono sposób dobierania właściwych narzędzi w zależności od wybranej opcji.
• Rozdział 4: Osiąganie pełnego pokrycia – w tym rozdziale nakreślono realistyczne oczekiwania dla długoterminowej mapy drogowej projektu automatyzacji, a także pokazano, w jaki sposób możemy zacząć czerpać z niej korzyści jeszcze na długo przed tym, jak automatyzacja zastąpi większość manualnych testów regresji.
• Rozdział 5: Procesy biznesowe – w tym rozdziale wyjaśniono, w jaki sposób automatyzacja testów powiązana jest z procesami biznesowymi wytwarzania oprogramowania i podano ogólny zarys tematów, które omawiane są bardziej szczegółowo pod koniec tej książki.
• Rozdział 6: Automatyzacja i architektura testów – w tym rozdziale omówiono sposób, w jaki automatyzacja testów jest powiązana z architekturą testowanego systemu, oraz dlaczego ważne jest, aby były one do siebie dostosowywane.
• Rozdział 7: Izolacja i środowiska testowe – w tym rozdziale wyjaśniono, w jaki sposób należy planować automatyzację testów oraz jej środowiska wykonywania, aby
zagwarantować, że testy są wiarygodne i nie mają na nie wpływu żadne niepożądane efekty.
• Rozdział 8: Szersza perspektywa – w tym rozdziale omówiono wzajemne zależności pomiędzy wszystkimi tematami omawianymi w poprzednich rozdziałach – głównie między architekturą, strukturą biznesu, procesami biznesowymi i oczywiście automatyzacją testów. Omówiono również sposób, w jaki wszystkie te tematy odnoszą się do kultury biznesu.
Część II:
• Rozdział 9: Przygotowanie do samouczka – ten rozdział zawiera opis proces wykorzystywany w ramach samouczka, który ma również zastosowanie w większości projektów automatyzacji testów. W rozdziale tym pokazano również, jak można skonfigurować własną maszynę, aby móc samodzielnie wykonywać kolejne kroki tego samouczka.
• Rozdział 10: Projektowanie pierwszego przypadku testowego – w tym rozdziale uczymy się konkretnej techniki projektowania przypadków testowych w sposób najlepiej pasujący do testów automatycznych.
• Rozdział 11: Kodowanie pierwszego testu – w tym rozdziale pokazano, w jaki sposób możemy rozpocząć pisanie kodu dla pierwszego testu. Zaczynamy od napisania prostego szkieletu testu, w sposób, który pozwoli nam zaprojektować i utworzyć modułową infrastrukturę do wielokrotnego użytku. Pod koniec tego rozdziału nasz test będzie się kompilował, ale nie będzie on wykonywał jeszcze żadnej pracy.
• Rozdział 12: Uzupełnianie pierwszego testu – w tym rozdziale kończymy pracę, którą zaczęliśmy w rozdziale poprzednim. Pod koniec tego rozdziału będziemy mieć działający test oraz dobrze zaprojektowaną infrastrukturę, która będzie go obsługiwać.
• Rozdział 13: Badanie niepowodzeń – w tym rozdziale ćwiczymy sposób badania i radzenia sobie z rzeczywistym niepowodzeniem testu, które miało miejsce w nowej kompilacji testowanego systemu, oraz tworzenia raportu, który pomoże nam zbadać dodatkowe niepowodzenia w przyszłości.
• Rozdział 14: Dodawanie kolejnych testów – w tym rozdziale dodajemy jeden dodatkowy test. Ponadto omawiamy sposób dodawania coraz większej liczby testów przy jednoczesnym rozszerzaniu i usprawnianiu wspierającej ich infrastruktury, w tym obsługę testowania w wielu przeglądarkach, obsługę wielu środowisk i znacznie więcej.
• Rozdział 15: Ciągła integracja – w tym rozdziale (rozpoczynającym drugą grupę rozdziałów z części II) wyjaśniono, w jaki sposób możemy integrować testy do postaci kompilacji ciągłej integracji. Poza aspektami technicznymi, w rozdziale tym pokazano, jak zapewnić sukces ciągłej integracji jako narzędzia organizacyjnego i podano porady dla osób bez doświadczenia w programowaniu, jak stopniowo zmieniać na lepsze kulturę i procesy danej organizacji poprzez wykorzystywanie zalet ciągłej integracji.
• Rozdział 16: Tworzenie oprogramowania sterowane testami akceptacyjnymi (ATDD) – w tym rozdziale wyjaśniono korzyści ze stosowania oraz sposób implementacji metodyki tworzenia oprogramowania sterowanego testami akceptacyjnymi, która dzięki wykorzystaniu ciągłej integracji obejmuje cały cykl tworzenia oprogramowania i pomaga zespołowi efektywnie wykorzystywać metodykę Agile.
• Rozdział 17: Testy jednostkowe i tworzenie oprogramowania sterowane testami (TDD) – w tym rozdziale omówiono techniki, które tradycyjnie przypisywane są wyłącznie programistom aplikacji: testy jednostkowe i tworzenie oprogramowania sterowane testami, ale są tak naprawdę nieodłączną częścią automatyzacji testów.
• Rozdział 18: Inne rodzaje testów automatycznych – w tym rozdziale omówiono dodatkowe rodzaje testów automatycznych, w tym testowanie wydajności i obciążenia, testowanie w środowisku produkcyjnym, testowanie wizualne, testy instalacji, testowanie z wykorzystaniem sztucznej inteligencji i więcej.
• Rozdział 19: Co dalej? – w tym rozdziale podano pewne wskazówek dotyczące dalszego zdobywania i rozwijania umiejętności w zakresie automatyzacji testów.
Poza tymi rozdziałami, na końcu książki dostępne są również cztery dodatki:
• Dodatek A: Rzeczywiste przykłady – ten dodatek stanowi uzupełnienie rozdziału 6 („Automatyzacja i architektura testów”) i zawiera cztery rzeczywiste przykłady architektur aplikacji oraz odpowiadające im rozwiązania automatyzacji.
• Dodatek B: Mechanizm oczyszczania – ten dodatek zawiera opis sposób budowy mechanizmu oczyszczania, przedstawionego w rozdziale 7 („Izolacja i środowiska testowe”).
• Dodatek C: Projekt „Test Automation Essentials” – w tym dodatku opisałem stworzony przeze mnie projekt open source o nazwie Test Automation Essentials, zawierający wiele przydatnych narzędzi kodu (napisanych w C#) dla projektów automatyzacji testów.
• Dodatek D : Wskazówki i praktyki zwiększające produktywność programisty – ten dodatek stanowi uzupełnienie dla rozdziałów od 9 do 14 i zawiera wskazówki, które pozwolą nam zwiększyć produktywność podczas programowania. Choć wskazówki te mogą być przydatne dla dowolnego programisty, będą one szczególnie użyteczne dla programistów automatyzacji testów.
Przyjemnej lektury!
Wartość automatyzacji testów
Ponieważ tematem tej książki jest automatyzacja testów, powinniśmy w zasadzie zacząć od jej definicji. Jednak bez nakreślenia właściwego kontekstu definicja taka może nie być wystarczająco przejrzysta i może bardziej prowadzić do dezorientacji niż zrozumienia. Jest to na tyle szeroki i zróżnicowany temat, że trudno jest tu podać taką definicję, która będzie jednocześnie dokładna, przejrzysta i obejmie wszystkie istniejące rodzaje automatyzacji testów. Gdybym jednak miał teraz przytoczyć jakąś definicję, mogłaby ona wyglądać tak: „Używanie oprogramowania w celu ułatwienia testowania innego oprogramowania”, ale nie jestem do końca pewien, na ile jest ona przydatna. Dlatego też zamiast skupiać się na formalnych definicjach, w pierwszej części książki szczegółowo analizuję ten obszerny temat, starając się w ten sposób wyjaśnić, czym tak naprawdę jest automatyzacja testów, a także – co równie istotne – czym ona nie jest!
Dlaczego potrzebujemy automatyzacji testów?
Gdy pytam moich klientów, czego spodziewają się uzyskać dzięki automatyzacji testów, najczęściej udzielaną odpowiedzią jest skrócenie czasu potrzebnego na przetestowanie oprogramowania przed jego wydaniem. Z jednej strony, choć jest to niewątpliwie ważny cel, to w zakresie korzyści, jakie możemy uzyskać dzięki automatyzacji testów, stanowi on jedynie wierzchołek góry lodowej. Ponadto osiągnięcie celu w postaci skrócenia cykli testów manualnych zajmuje zwykle sporą ilość czasu. Z drugiej strony, dużo wcześniej możemy zacząć zauważać pozostałe korzyści. Ale najpierw zobaczmy, dlaczego ten prosty cel w postaci skrócenia czasu trwania cyklu testowego stał się w ostatnich latach tak istotny.
Od modelu kaskadowego do zwinnego tworzenia oprogramowania
Mimo że niektóre organizacje korzystają z automatyzacji testów już od dekad, jednak zaczęła być ona powszechnie stosowana dopiero w ostatnich latach. Jest wiele powodów, dla których tak się stało, ale bez wątpienia można powiedzieć, że wzrost zapotrzebowania na automatyzację testów zawdzięczamy w dużej mierze odejściu od tradycyjnego modelu kaskadowego (waterfall) na rzecz programowania zwinnego (Agile software development). W tradycyjnym podejściu kaskadowym projekty oprogramowania postrzegane były jako coś jednorazowego, podobnie jak budowanie mostu. Najpierw planujemy i projektujemy oprogramowanie, potem je budujemy, a na końcu testujemy i sprawdzamy jakość końcowego produktu, naprawiając przy tym pomniejsze błędy, które znaleźliśmy. Opieramy się tu na założeniu, że jeśli fazy planowania i budowy zostały przeprowadzone poprawnie, to poza pewnymi drobnym pomyłkami programistycznymi, które możemy bardzo łatwo naprawić, wszystko powinno działać zgodnie z planem. Takie podejście sprawia, że proces weryfikowania, czy rezultat końcowy zachowuje się zgodnie ze specyfikacją, musimy przeprowadzić tylko raz. Ponowne wykonanie testu powinno mieć miejsce tylko w przypadku wykrycia jakiegoś błędu i przygotowania dla niego odpowiedniej poprawki, a następnie jej sprawdzenia. Jeśli każdy test wykonywany jest tylko raz lub dwa razy, to w wielu przypadkach znacznie taniej i łatwiej będzie wykonywać je ręcznie niż je automatyzować. Po latach stało się jasne, że w większości przypadków podejście kaskadowe nie spełnia swoich obietnic. Większość projektów oprogramowania była już na tyle skomplikowana, że zaplanowanie i domknięcie wszystkich technicznych szczegółów w początkowej fazie tworzenia było niemożliwe. Nawet w tych przypadkach, w których było to wykonalne, do czasu ukończenia takiego projektu (trwającego zwykle kilka lat) zmieniały się zarówno sama technologia, jak i potrzeby biznesowe, czyniąc takie oprogramowanie mniej adekwatnym niż miało być początkowo. Z tych właśnie powodów szybkie reagowanie na opinie klientów stało się cenniejsze od sztywnego trzymania się początkowego planu. Wraz z upływem czasu większość przemysłu oprogramowania odeszła od tych jednorazowych projektów, rezygnując z cyklicznego wydawania nowych wersji tego samego oprogramowania co kilka lat na rzecz szybkich cyklów wydawniczych. Dzisiaj niektóre z największych firm działających w sieci Web dostarczają nowe funkcje i poprawki dla swojego oprogramowania po kilka razy dziennie, a niekiedy nawet kilka razy na minutę!1
maniFeStproGramowaniazwinneGo w 2001 roku 17 liderów z obszar u rozwoju oprogramowania sformułowało Manifest programowania zwinnego, którego treść jest następująca1 : odkrywamy nowe metody programowania dzięki praktyce w pr ogramowaniu i wspieraniu w nim innych.w wyniku naszej pracy zaczęliśmy bardziej cenić: Ludzi i interakcje od pr ocesów i nar zędzi Działające oprogramowanie od szczegółowej dokumentacji
1 Tłumaczenie treści manifestu pochodzi ze strony: http://agilemanifesto.org/iso/pl/manifesto.html (przyp. tłum.)
• Gdy analizujemy testy kończące się niepowodzeniem, upewnijmy się, że mamy wszystkie niezbędne informacje, które pomogą nam zbadać je szybciej.
• W przypadku napotkania nieoczekiwanych rezultatów z powodu problemów związanych z izolacją, usprawniamy izolację.
• Jeśli chcemy przekazać innym osobom nasze testy do uruchomienia, upewnijmy się, że są one wystarczająco łatwe w użyciu.
Poznawanie testowanego systemu
W samouczku tym korzystamy z projektu open source o nazwie MVCFor um. MVCForum jest w pełni funkcjonalnym, responsywnym i obsługującym motywy forum dyskusyjnym z funkcjami podobnymi do witryny StackOverflow. Projekt ten napisany został w języku C# z użyciem biblioteki ASP.NET MVC 5. Strona domowa tego projektu znajduje się pod adresem http://www.mvcforum.com, zaś jego najnowszy kod źródłowy jest dostępny pod adresem https://github.com/YodasMyDad/mvcforum. Ponieważ projekt ten mógł ewoluować od czasu napisania tej książki, sklonowaliśmy jego repozytorium GitHub, tak aby samouczek ten zawsze nadawał się do użytku.
Omówienie projektu MVCForum
Aplikacja ta jest dosyć bogata w funkcje, a do najważniejszych z nich należą:
• silnik motywów,
• system odznak społecznościowych,
• obsługa wielu języków,
• przesyłanie wiadomości prywatnych,
• polubienia, oznaczanie rozwiązań, ulubione.
Pełna lista dostępnych funkcji znajduje się na stronie głównej witryny GitHub tego projektu29 . Tak czy inaczej, najprostszym sposobem zapoznania się z tą aplikacją jest przejście na stronę https://support.mvcforum.com/, która jest zarządzana za pomocą samej tej aplikacji (witryna ta nie jest pod naszą kontrolą, tak więc używana w niej wersja aplikacji może być nowsza, a sama strona może być nawet niedostępna). Zakładając, że witryna ta nie została zmieniona w zbyt dużym stopniu, powinna ona wyglądać podobnie do tej przedstawionej na rysunku 9.1.
29 Wersja wykorzystywana w tym samouczku znajduje się pod adresem http://github.com/arnonax/mvcforum. Aktualna jej wersja dostępna jest pod adresem https://github.com/YodasMyDad/mvcforum, ale należy postępować ostrożnie, ponieważ nie ma gwarancji, że będzie ona nadal zgodna z tą książką.
Rysunek 9.1. Główna strona witryny wsparcia dla aplikacji MVCForum
Jak widzimy, witryna ta wyświetla listę ostatnio prowadzonych dyskusji. Wszystkie dyskusje możemy czytać bez konieczności rejestrowania się lub logowania. Po zarejestrowaniu (które jest darmowe) użytkownicy mogą tworzyć nowe dyskusje i zamieszczać komentarze w istniejących dyskusjach. Dyskusje przypisywane są do określonej kategorii i mogą mieć również zdefiniowane znaczniki, za pomocą których możemy wyszukiwać interesujące nas dyskusje.
Poza tą podstawową funkcjonalnością, forum to pozwala zarejestrowanym użytkownikom na wystawienie oceny każdej dyskusji lub komentarza innej osoby (lubię/nie lubię), a także pozwala inicjatorowi dyskusji oznaczyć jeden komentarz jako poprawną odpowiedź lub rozwiązanie. Na podstawie różnych reguł i opcji, które może skonfigurować administrator witryny, użytkownicy mogą zdobywać punkty i odznaki. Użytkownicy o największej liczbie punktów zebranych w danym tygodniu lub roku są wyświetlani na tablicy wyników Leaderboard (patrz rysunek 9.2).
Ciągła integracja
Większości deweloperów zna jest dobrze znane pojęcie „ciągłej integracji” (Continuous Integration, w skrócie CI). Jak wspomnieliśmy w rozdziale 2, termin ten oznacza, że przed każdą operacją ewidencjonowania (check-in), kod jest automatycznie kompilowany i weryfikowany przez automatyczne testy. Zmiany ewidencjonowane są tylko wtedy, gdy wszystkie testy kończą się sukcesem. Proces, który kompiluje kod i uruchamia testy, zwykle działa na jednym lub kilku dedykowanych serwerach kompilacji, a nie na maszynie dewelopera. Pozwala to na scentralizowane sterowanie tym procesem, a także umożliwia wykonywanie innych zadań na maszynie dewelopera w czasie działania tego procesu.
pomnieJSzewariantyciĄGŁeJinteGracJi
choć powyższy opis ciągłej integracji (ci) jest obecnie najbardziej typowy, istnieją również inne warianty tego pojęcia. warianty te były częściej stosowane w pr zeszłości, przy czym dzisiaj nadal są one dosyć powszechne. ponieważ są one również prostsze, czasem korzysta się z nich w mniejszych zespołach.
1.zamiast kompilować kod i ur uchamiać testy przed wprowadzeniem zmian do głównego repozytorium kontroli kodu, procesy te wykonywane są po zakończeniu tej operacji. ponieważ w takim wypadku niemożliwe jest powstrzymanie operacji check-in, proces kompilacji (który obejmuje kompilację i testy) raportuje jedynie, czy proces zakończył się sukcesem, czy niepowodzeniem. często rezultaty te są również wysyłane automatycznie do odpowiednich osób poprzez e-mail, a głównie do dewelopera, który dokonał operacji check-in. Jeśli kompilacja zakończy się niepowodzeniem, dobrą praktyką jest, aby deweloper jak najszybciej naprawił ten błąd, zanim ktokolwiek inny będzie mógł zaewidencjonować inne zmiany. 2.drugi wariant stosowany jest zwykle w bar dzo małych zespołach lub gdy nikt nie posiada umiejętności pozwalających na zainstalowanie i skonfigur owanie serwera kompilacji. choć wariant ten jest zwykle mniej prefer owany, gdyż opiera się on bardziej na samodyscyplinie niż na narzędziach, to nadal wyraża on istotę i ideę stojącą za pojęciem ci. w wariancie tym każdy programista pobiera najnowszy kod, kompiluje i ur uchamia testy lokalnie, i wykonuje operacje check-in tylko wtedy, gdy wszystkie testy kończą się sukcesem.
Przejście z kompilacji nocnych do CI może stanowić pewne wyzwanie. Ale ostatecznie uzyskiwane w ten sposób korzyści przewyższają te problemy. Więcej informacji na temat właściwego sposobu dokonania tego przejścia można znaleźć w rozdziale 15.
Choć ciągła integracja pozwala odpowiedzieć na pytania dotyczące tego kto, kiedy i jak powinien uruchamiać testy, nie daje ona odpowiedzi na pytania: kto, kiedy i jak powinien pisać testy. W rozdziale 3 udzieliliśmy odpowiedzi na pytanie „kto powinien implementować testy”. Ponadto w rozdziałach 2 i 3 mówiliśmy o tym, dlaczego lepiej jest pisać testy podczas opracowywania funkcji, a nie po ich ukończeniu. W rozdziale 16 omawiamy ten
Oto lista klas, metod i właściwości, które trzeba dodać, aby można było skompilować
kod:
• public AdminConsole MVCForum.AdminConsole { get; }
Uwaga
Zmieniliśmy nazwę z AdminPage na AdminConsole , zatem w rzeczywistości jest to istniejąca klasa.
• public Category AdminConsole.CreateCategory()
• public DiscussionBuilder Discussion.Category(Category category)
• public CategoriesList MVCForum.Categories { get; }
• public class CategoriesList
– public CategoryView Select(Category category)
• public class CategoryView
– public IReadOnlyCollection<DiscussionHeader> Discussions
Uwaga
Nadal nie wyodrębniliśmy wspólnej klasy bazowej z klas Discussion i DiscussionHeader Zrobimy to dopiero wtedy, gdy konieczne będzie pomyślne wykonanie instrukcji Assert.
Usuwanie duplikacji między MVCForum.AdminConsole i AddCreateTopicPermissionToStandardMembers
Gdy nasz test już się skompiluje i zostanie uruchomiony, wówczas pierwszy napotkany przez nas wyjątek NotImplementedException dotyczyć będzie właściwości MVCForum. AdminConsole. Jak wspomnieliśmy wcześniej, kod logowania się jako administrator i nawigowania do konsoli administratora jest już zawarty w metodzie AddCreateTopicPermissionToStandardMembers, która jest wywoływana z metody TestInitialize. Listing 14.4 pokazuje bieżącą implementację metody AddCreateTopicPermissionToStandardMembers. Pogrubione wiersze są tymi, które chcemy wyodrębnić do właściwości MVCForum. AdminConsole.
Uwaga
W poprzednim rozdziale do projektu dodaliśmy wizualny rejestrator, ale oprócz tego kod, który istniał w metodzie TestInitialize, wyodrębniliśmy do metody AddCreateTopicPermissionToStandardMembers, aby oddzielić go od inicjalizacji samego rejestratora.
