Redakcja
Odseparowanie środowiska testowego od produkcyjnego to oczywista oczywistość, ale co jeszcze musimy mieć w naszym środowisku, aby uznać, że mamy pełną kontrolę i nikt nie zepsuje nam naszych testów? Oczywiście nie o samo zepsucie tu chodzi, ale również, a może przede wszystkim o:
- płynne przejście przez testy bez problemów z niedostępnością środowiska,
- unikanie zgłoszeń fałszywie negatywnych wyników,
- unikanie kolizji z innymi użytkownikami na środowisku,
- niekontrolowane zmiany wersji.
7 najważniejszych elementów, jakie mieć musisz, aby mieć pełną kontrolę.
1. Kontrolę nad tym kto, kiedy i dlaczego wgrywa wersję
Nie pozwól by ktokolwiek, bez Twojej wiedzy i zgody podmieniał ci wersję, robił "szybkiego fix-a" lub "na chwilę cię wyłączył". Każde takie zaburzenie przerywa testy i jest zagrożeniem dla wcześniej zdefiniowanych planów.
2. Pełna kontrola nad uprawnieniami
Nie chcesz aby w środku testów okazało się, że nie możesz wykonać jakiejś operacji, ponieważ istnieje jakiś użytkownik, który Twoje działanie musi zaaprobować. Nie chcesz dowiedzieć się, że dana operacja jest niedozwolona dla użytkownika o twoich uprawnieniach. Każda z tych sytuacji to potencjalny bloker i brak możliwości kontynuowania testów.
3. Kontrola nad danymi testowymi na środowisku
Chcesz wiedzieć, jakie dane są w środowisku. Nie ma znaczenia, czy są to dane produkcyjne, mieszane, zanonimizowane. Twoje działania w systemie często opierają się na heurystyce CRUD i bez świadomości danych tracisz punkty efektywności.
4. Dostęp do hardware’u
Jeśli coś niespodziewanie padnie lub zawiesi się, chcesz szybko wrócić do testów. Czasami nie będzie to możliwe bez klucza do serwerowni, który aktualnie ma admin, który aktualnie jest na obiedzie. W pracy zdalnej jest jeszcze gorzej, bo musisz wiedzieć do kogo zadzwonić, aby podniósł Ci lub zrestartował środowisko.
5. Kontrola nad dostępami oraz aktualnymi użytkownikami na środowisku
Dziesiątki ludzi pracujący na tym samym koncie prędzej czy później wejdą ze sobą w kolizję procesów lub danych. Dlatego warto wiedzieć, kto aktualnie jest na środowisku i co robi. Czasami trafi się słoń w składzie porcelany, który zacznie losowo kasować rekordy, na których ty aktualnie pracujesz. Nie chcesz tego.
6. ZaMOCKowane wszystkie zewnętrzne aplikacje, nad którymi nie mamy kontroli
Gdy dalsze działanie twojego testu zależy od odpowiedzi zewnętrznego systemu, który aktualnie jest niedostępny, to znów trafiasz na ścianę. Mock daje ci kontrolę nad komunikacją i pozwala przywrócić testy na ich ścieżkę.
7. Dostęp do bazy danych z możliwościami zmian bezpośrednio na bazie
Oczywiście z dużą ostrożnością powinniśmy podchodzić do modyfikacji na bazie, bo ani to standardowe, ani optymalne w testach. Jeśli jednak trzeba na szybko ustawić flagę, aby coś przyspieszyć, to czasami nie ma wyjścia. Traktujcie to uprzywilejowanie jako ostateczną deskę ratunku.
Należy pamiętać, że kontrola nad środowiskiem to nie tylko przywilej, ale również duża odpowiedzialność. Środowiska rzadko kiedy tworzy się pod jednego testera, a zazwyczaj jest ono współdzielone. Uprawnienia, jakie opisujemy powyżej, definiują administratora środowiska testowego, a co za tym idzie osobę, która bierze na siebie odpowiedzialność za pracę i swoją, i innych osób w tym środowisku.
