Jeżeli Twoje rozwiązanie opiera się głównie o testy manualne, to na płynność ich wykonywania, może teraz mieć negatywny wpływ ogólne obciążenie sieci internetowej. Wiadomo, teraz prawie cały świat, o ile może, to pracuje z domu. choćby platformy wideo ograniczają maksymalną rozdzielczość dostarczanych materiałów. Pracując z domu, łącząc się do serwera testowanej aplikacji, korzystając z połączenia **VPN**, możesz nie mieć takiej samej przepustowości jak w biurze. A to wydłuża czas wykonywania testów, jak i zwiększa Twoją frustrację. Może to dobry moment, aby w końcu zacząć wdrażać automatyzację?
W przypadku testów automatycznych najważniejszą zasadą jest: nie uruchamiaj testów ze swojego komputera. To jest Twoja maszyna do tworzenia testów, a nie do ich uruchamiania. Tak samo jak w przypadku oprogramowania, które testujesz. Nie zgadzasz się przecież testować go na maszynie programisty, tylko jest ono wrzucane na środowisko testowe. Ten sam reżim powinieneś/-aś wprowadzić dla testów automatycznych.
Dzięki takiemu podejściu zapewniasz swoim testom dodatkową stabilność i powtarzalność. Nie są już one zależne od lokalizacji twojego komputera i jego obciążenia. Jednym słowem, nieważne gdzie jesteś i skąd uruchamiasz testy, wykonują się one zawsze w zbliżonych warunkach, a co najważniejsze, mogą się one ograniczyć do firmowego intranetu, więc w tej chwili panujące warunki nie powinny mieć na nie żadnego wpływu.
## Build serwer / CI
źródło: [https://pixabay.com/illustrations/devops-business-process-improvement-3148393/](https://pixabay.com/illustrations/devops-business-process-improvement-3148393/)
Skoro nie powinieneś/-aś uruchamiać testów na swoim komputerze, to uruchamiaj je na zewnętrznym serwerze, na build serwerze. Najczęściej używane w tej chwili produkty to [Jenkins](https://www.jenkins.io/) lub [TeamCity](https://www.jetbrains.com/teamcity/).
Pamiętaj, iż na początek to nie musi być odrazu pełny proces CI, gdzie testy są automatycznie odpalane po każdej kompilacji i po każdym nowym deploymencie aplikacji. o ile to jest Twoje pierwsze podejście do integracji testów automatycznych z build serwerem, warto zacząć od najprostszego rozwiązania: testy uruchamiane manualnie na serwerze. To i tak jest dużo, dużo lepsze rozwiązanie, niż testowanie z własnej maszyny, i od tego radzę zacząć. Na większą automatyzacje przyjdzie jeszcze czas…
Jeżeli Twoje testy automatyczne są oparte o jeden z wielu języków programowania (Python, Java, C# itp itd) wraz z dedykowaną biblioteką, ułatwiającą pisanie testów (np. RestAssured dla Javy) to nie powinieneś/-aś mieć problemu z uruchomieniem tych testów na systemie CI. Wszakże, uruchomienie takich testów praktycznie nie różni się od budowania aplikacji, którą trzeba przetestować. Upewnij się tylko, iż serwer CI ma dostęp do testowanej usługi. Wykorzystaj tą samą komendę, którą uruchamiasz testy ze swojej maszyny.
## Postman
źródło: [https://www.pngkit.com/downpic/u2w7w7o0q8i1o0a9_the-postman-logo-is-available-in-png-svg/](https://www.pngkit.com/downpic/u2w7w7o0q8i1o0a9_the-postman-logo-is-available-in.webp-svg/)
Jeżeli Twoje rozwiązanie testów automatycznych jest oparte o Postman’a, tutaj jest trochę komplikacji, ale co najważniejsze, przez cały czas jest to możliwe. W tym przypadku na pomoc rusza narzędzie zwane [Newman](https://github.com/postmanlabs/newman). Jest to narzędzie, które pozwala na uruchamianie kolekcji Postman’owych z poziomu lini poleceń z pominięciem samego Postman’a. Musisz teraz wyeksportować swoją kolekcje testów, a następnie:
```
newman run
```
oczywiście zamiast `````` podstaw nazwę pliku z Twoimi testami. o ile korzystasz ze zmiennych środowiskowych, jak również, z predefiniowanych zmiennych globalnych, newman również pozwala na ich użycie, dodaj do komendy opcje:
```
--globals --environment
```
Newman obsługuje również plik z zestawem danych do testów parametryzowanych. W przeciwieństwie do Postmana wspiera tylko format CSV, więc o ile do tej pory korzystałeś z danych w postaci plików JSON, to czeka Cię konwersja do odpowiedniego formatu. Potem już tylko pozostaje ci rozszerzyć komendę o dodatkową opcję:
```
--iteration-data
```
Podsumowywując, newman daje Ci możliwość uruchamiania testów Postmanowych, wykorzystując wszystkie potrzebne funkcjonalności zaszyte w oryginale. Dzięki temu nie powinieneś mieć już problemu z uruchamianiem takich testów z poziomu serwera CI.
## Testy Web UI
źródło: [https://pixabay.com/illustrations/software-testing-service-762486/](https://pixabay.com/illustrations/software-testing-service-762486/)
Jeżeli do testów automatycznych potrzebujesz przeglądarki, przez cały czas możesz wykonanie takich testów zlecić serwerowi CI. Musisz tylko rozwiązać problem *Jak dostarczyć przeglądarkę do serwera?* Tutaj masz dostępne dwa podstawowe rozwiązania.
### 1. Tryb headless
Firefox oraz Chrome pozwalają na uruchomienie się w tzw. trybie *“headless”*. Jest to tryb, w którym przeglądarka nie wyświetla swojego okna, wszystko się dzieje w pamięci operacyjnej systemu. Poza tą drobną różnicą, wszystkie pozostałe funkcjonalności pozostają bez zmian, Działa również robienie zrzutów ekranu, o ile korzystasz z funkcji wbudowanych w Web Driver’a, a nie korzystasz z wywołań systemowych.
Jeżeli zdecydujesz się na korzystanie z tego podejścia, wystarczy, iż na serwerze, na którym stoi system CI zainstalujesz potrzebną Ci przeglądarkę, a w testach odpalisz ją w trybie *“headless”*. Więcej informacji dla Firefox’a znajdziesz [tutaj](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Headless_mode), a dla Chrome’a [tutaj](https://developers.google.com/web/updates/2017/04/headless-chrome).
### 2. Selenium Grid
Powyższe rozwiązanie ma jedną wadę: obciąża dodatkowo serwer CI, co zwykle nie jest akceptowalne. o ile z tego serwera korzysta wiele projektów, ich budowanie oraz uruchamianie testów jednostkowych może się znacznie wydłużyć, co nie jest pożądane. Na ratunek przychodzi *Selenium Grid*, czyli dedykowany serwer, którego udostępnianą usługą są przeglądarki (w większości przypadków uruchamiane w trybie *headless*).
Jak już zdecydujesz się na to rozwiązanie, lub chcesz tylko spróbować, to radzę skorzystać z jednego z gotowych rozwiązań. Największą zaletą z takiego podejścia jest prostota uruchomienia takiego serwisu, w dobie wszędobylskiego docker’a jest to jedna komenda i serwer działa, i można z niego korzystać. Drugą zaletą są dodatkowe funkcjonalności takie jak rozszerzone raportowanie, czy nagrywanie okna przeglądarki w trakcie wykonywania testu, aby można było sobie potem takie nagranie odtworzyć i sprawdzić co dokładnie poszło nie tak.
Z mojej strony mogę zarekomendować dwa takie gotowce Selenium Grid: [Selenoid](https://github.com/aerokube/selenoid) oraz [Zalenium](https://opensource.zalando.com/zalenium/). Sprawdź sam i przekonaj się jakie to proste.
## Podsumowanie
Jeżeli efektywność Twoich testów w dobie koronawirusa jest taka sama jak przed, brawa dla Ciebie! Masz dobrze wszystko przemyślane i Twój projekt przechodzi test koronawirusa. o ile jednak tak nie jest, może to dobry moment aby sprawdzić co można poprawić, aby w przyszłości nie miało znaczenia skąd przeprowadzasz swoje testy. A jak już to poprawisz, to może będzie dobra okazja aby kupić kampera i ruszyć w trasę, oczywiście ciągle pracując z miejsc, gdzie akurat się zatrzymałeś….
