Po co automatyzować testy obciążeniowe w CI/CD zamiast robić je „od święta”
Koszt regresji wydajności na produkcji kontra tani test w pipeline
Regresja wydajności odkryta dopiero na produkcji to zazwyczaj najdroższy możliwy wariant: eskalacje od klientów, nerwowe rollbacki, gaszenie pożarów przez seniorów, nadgodziny, a na końcu i tak dochodzi refaktoryzacja. W wielu firmach koszt jednego większego incydentu wydajnościowego spokojnie przekracza koszt kilku tygodni pracy całego zespołu nad sensowną automatyzacją testów obciążeniowych w CI/CD.
Automatyzacja testów obciążeniowych w CI działa jak tania ubezpieczeniowa bariera: zamiast jednego długiego, drogiego testu „przed dużym releasem” pojawia się seria krótkich, powtarzalnych kontroli przy każdym merge’u lub przynajmniej raz dziennie. Każdy z takich testów jest krótki, ograniczony zasięgiem i uruchamiany automatycznie, a jego koszt to głównie kilkanaście minut maszyny CI oraz raz napisana logika oceny wyników.
Różnica w rachunku jest brutalnie prosta: jedno większe potknięcie wydajnościowe na produkcji może kosztować więcej niż cały rok uruchamiania sensownie zaprojektowanych testów obciążeniowych w pipeline. Do tego dochodzi koszt reputacyjny – spadające SLO i SLA, zrywane umowy, frustracja działu sprzedaży. Krótki test smoke performance w CI/CD, który zatrzyma regresję przed deploymentem, jest pod tym kątem jedną z najbardziej opłacalnych inwestycji w pipeline.
Wydajność jako warunek „build passed”, a nie jako kwartalny audyt
W wielu organizacjach wydajność jest traktowana jak audyt bezpieczeństwa sprzed lat: raz na kwartał ktoś odpala JMetera, generuje ładny raport PDF, a później nikt do niego nie wraca. Rezultat: zespół przez większość czasu nie widzi wpływu swoich zmian na performance, więc naturalnie ignoruje ten aspekt na etapie implementacji.
Automatyzacja performance tests w CI zmienia kulturę: zielony build to nie tylko „testy jednostkowe i integracyjne przeszły”, ale też „kluczowe scenariusze utrzymały parametry wydajności”. Zmiana jest psychologiczna, ale działa niezwykle skutecznie: jeśli każdy merge request może zostać zablokowany przez regresję P95 czy wzrost error rate, programiści zaczynają myśleć o wydajności już przy pisaniu kodu.
Przy odpowiednim ustawieniu progów i dobrym dobraniu scenariuszy test obciążeniowy staje się tak samo naturalną częścią pipeline, jak testy funkcjonalne. Nie ma potrzeby specjalnych „kampanii wydajnościowych” przed każdym releasem – system jest mierzalny ciągle, a regresje wykrywane wcześnie, zanim się nagromadzą.
Pełny test wydajności vs szybka „kontrola graniczna” w CI
Pełne kampanie wydajnościowe trwające kilka godzin, obejmujące dziesiątki scenariuszy, symulujące realny ruch dobowy – to nadal potrzebny element dla większych systemów. Nie mają jednak sensu jako krok przy każdym pushu. Aby pipeline CI/CD był użyteczny, testy wydajności muszą być lekkie, szybkie i ukierunkowane na regresje, a nie na absolutne limity systemu.
„Kontrola graniczna” w CI powinna odpowiadać na jedno kluczowe pytanie: czy w porównaniu do poprzedniej stabilnej wersji nie pogorszyliśmy zauważalnie kluczowych metryk wydajności? Zwykle sprowadza się to do krótkiej próby (kilka–kilkanaście minut), ograniczonej liczby wirtualnych użytkowników i wąskiego zestawu endpointów, ale uruchamianej często.
Taki test nie zastąpi długiego soak testu czy badania pojemności, ale jest wystarczający, by wyłapać typowe regresje: wolniejsze zapytania do bazy, przypadkowe N+1, nieoptymalne zapytania do zewnętrznych usług, cofnięcie optymalizacji cache. To tych regresji jest najwięcej i to one najbardziej bolą w codziennej pracy.
Kluczowe cele automatyzacji testów obciążeniowych w pipeline
Z perspektywy CI/CD sens automatyzacji performance tests można streścić do kilku konkretnych celów:
Szybkie wykrywanie regresji wydajności – porównywanie wyników do poprzedniego stabilnego builda i blokowanie zmian, które pogarszają parametry powyżej ustalonego progu.
Ochrona SLO i SLA – utrzymanie zgłoszonych do biznesu i klientów poziomów dostępności oraz czasów odpowiedzi, zanim jeszcze kod trafi na produkcję.
Zmniejszenie ryzyka deployów – każdy releasowany build przechodzi choćby krótki smoke performance test, co znacząco ogranicza liczbę „niespodzianek” po wdrożeniu.
Stała widoczność trendów wydajności – nawet jeśli testy są krótkie, ich regularność pozwala budować wykresy trendów i wychwytywać powolne „pełzające” pogorszenia.
Lepsza dyscyplina techniczna – zespół bierze pod uwagę koszt wydajnościowy każdej funkcjonalności, bo widzi bezpośrednie skutki w raportach CI.
Podstawy testów obciążeniowych z perspektywy CI/CD
Typy testów wydajności a ich użyteczność w pipeline
Klasycznie rozróżnia się kilka rodzajów testów wydajności: load, stress, soak, spike, capacity. Z punktu widzenia CI/CD nie wszystkie mają sens jako kroki pipeline, przynajmniej nie przy każdym buildzie.
W skrócie:
Load test – obciążenie zbliżone do spodziewanego ruchu produkcyjnego. W CI można stosować jego uproszczoną, krótką wersję.
Stress test – sprawdzanie zachowania systemu przy obciążeniu powyżej normalnego, czasem aż do granicy załamania. Zwykle za ciężki na codzienny pipeline.
Soak test – długotrwały test (wiele godzin), sprawdzający wycieki pamięci, problemy z połączeniami, GC. Nadaje się do nocnych runów, nie do każdego commita.
Spike test – krótkie, nagłe zwiększenie ruchu; czasem da się go zastosować w CI, ale raczej jako osobny job przed releasem.
Capacity test – badanie maksymalnej pojemności systemu; to domena dedykowanych kampanii, nie pipeline per-commit.
Automatyzacja testów obciążeniowych w CI/CD skupia się najczęściej na uproszczonym load teście, pełniącym funkcję testu regresyjnego oraz lekkiej wersji spike testu (krótki peak ruchu). Dłuższe scenariusze sensowniej jest uruchamiać rzadziej – np. nocą lub przed dużymi wydaniami.
Minimalne metryki, które trzeba mierzyć w testach CI
Nawet najprostsze testy obciążeniowe w CI muszą mierzyć kilka kluczowych wskaźników, inaczej nie da się sensownie zdefiniować progów akceptacji. Podstawowy zestaw wygląda tak:
Czas odpowiedzi – średni, mediana, a przede wszystkim percentyle (p90, p95, czasem p99).
Throughput – liczba zapytań na sekundę / minutę; szczególnie ważna przy porównywaniu buildów.
Wskaźnik błędów – odsetek odpowiedzi z kodami 5xx, 4xx, ewentualnie specyficzne kody domenowe.
Stabilność w czasie – czy metryki utrzymują się na stałym poziomie w trakcie testu, czy rosną (np. wydłużający się czas odpowiedzi).
Jeżeli pipeline CI ma wykrywać regresje wydajności, metryki muszą być porównywalne między uruchomieniami. Dlatego testy powinny mieć powtarzalny przebieg: stały ramp-up, zbliżoną liczbę wirtualnych użytkowników i identyczne scenariusze. Każde losowe odchylenie utrudnia decyzję „pass/fail”.
Test wydajności jako test regresji, a nie abstrakcyjny benchmark
W praktyce rzadko opłaca się gonić za jakimś „idealnym” czasem odpowiedzi. Zamiast tego w CI bardziej sensowne jest traktowanie testu obciążeniowego jako testu regresji. Oznacza to porównywanie aktualnych wyników z wcześniej zaakceptowaną, dobrą wersją (baseline).
Zamiast sztywno oczekiwać „P95 < 300 ms”, można przyjąć regułę: „P95 nie może się pogorszyć o więcej niż 10–15% względem ostatniego zielonego builda”. Taki model lepiej uwzględnia realne warunki: sprzęt CI, drobne różnice środowiskowe, naturalną zmienność wyników.
Baseline można zbudować uruchamiając kilka pierwszych testów manualnie, wyciągając z nich medianę i percentyle, a następnie zapisując te wartości jako docelowe progi dla kolejnych runów. Z czasem, gdy architektura rośnie, baseline można aktualizować (np. przy większych refaktoryzacjach lub migracjach infrastruktury).
Stabilność środowiska – warunek sensownych testów w pipeline
Bez w miarę stabilnego środowiska zaufanie do testów wydajnościowych w CI szybko spada. Jeśli wyniki będą „skakać” przez losowe zakłócenia, zespół przestanie traktować czerwone buildy poważnie i zacznie je masowo ignorować lub omijać.
Podstawowe wymagania wobec środowiska dla testów obciążeniowych w pipeline:
Izolacja od innych ciężkich procesów – na tym samym serwerze nie powinno się równolegle wykonywać pełnych testów integracyjnych, migracji danych, dużych importów itp.
Stała konfiguracja – ta sama liczba instancji aplikacji, te same limity CPU/memory, takie same wersje komponentów (baza danych, cache, message broker).
Powtarzalne dane testowe – brak drastycznych zmian w dataset między uruchomieniami.
Przewidywalna sieć – unikanie testowania przez niestabilne VPN, losowe tunelowanie itp., jeśli to możliwe.
Nawet jeśli środowisko nie jest idealnym klonem produkcji, ważne, by było stabilne względem siebie. Wtedy różnice w wynikach między buildami można upatrywać w zmianach kodu, a nie w losowych warunkach uruchomienia.
Które testy obciążeniowe mają sens w CI/CD, a które zostawić na osobne kampanie
Szybkie testy regresyjne w CI kontra długie kampanie wydajnościowe
Automatyzacja performance tests nie oznacza, że wszystko musi się uruchamiać przy każdym commicie. Logicznie jest podzielić testy wydajnościowe na dwie kategorie:
Szybkie testy regresyjne w CI – krótka długość (5–15 minut), ograniczona liczba scenariuszy, niskie do średnie obciążenie, uruchamiane per-merge-request albo przynajmniej raz dziennie.
Długie testy capacity/soak – trwające godzinami, obciążające system do limitów, uruchamiane rzadziej: np. nocą, raz w tygodniu lub przed dużym wydaniem.
Pipeline CI/CD powinien być szybki i przewidywalny. Jeśli do każdego builda dołożymy godzinny test pojemnościowy, zespół zacznie go obchodzić (np. ręcznymi deployami), a całe przedsięwzięcie straci sens. Długie testy lepiej uruchamiać jako osobne pipeline’y, np. „perf-nightly”, z możliwością łatwego przejrzenia raportów rano.
Koncepcja „performance smoke tests” – tanie testy o wysokiej wartości
Tak jak istnieją smoke testy funkcjonalne, które w kilka minut sprawdzają czy aplikacja w ogóle działa po deployu, tak można zbudować zestaw performance smoke tests do użycia w CI. To minimalny, ale dobrze dobrany wycinek testów wydajności:
kilka kluczowych ścieżek użytkownika (np. logowanie, wyszukiwanie, kluczowy flow biznesowy),
umiarkowane obciążenie (kilkudziesięciu–kilkuset wirtualnych użytkowników w zależności od systemu),
czas trwania kilku minut po krótkim ramp-upie.
Performance smoke tests mają kilka zalet: są szybkie, stosunkowo tanie infrastrukturalnie i jednocześnie bardzo czułe na regresje w miejscach, które najbardziej dotykają użytkowników. To idealny kandydat na krok „performance-check” w pipeline przed merge’em do głównej gałęzi.
Odrzucanie scenariuszy o małej wartości biznesowej
Naturalną pokusą przy projektowaniu testów obciążeniowych jest pokrycie „wszystkiego”. Z punktu widzenia CI/CD to droga donikąd. Czas pipeline’u i zasoby infrastruktury są ograniczone, więc kluczowa jest selekcja scenariuszy wg realnej wartości.
Dobrym krokiem jest zbudowanie prostej macierzy priorytetów dla endpointów lub flowów aplikacji, biorąc pod uwagę:
Krytyczność biznesową – bez których funkcji system jest praktycznie bezużyteczny?
Wolumen ruchu – które endpointy obsługują największy ruch w ciągu dnia?
Wrażliwość użytkownika na opóźnienie – gdzie użytkownik szybko zrezygnuje po kilku sekundach czekania?
Scenariusze o niskim ruchu, małej krytyczności biznesowej i niskiej wrażliwości na opóźnienia można pozostawić wyłącznie dla kampanii okresowych, jeśli w ogóle. W CI/CD skupienie się na top 3–5 scenariuszach często generuje 80% wartości, przy zaledwie 20% kosztu względem pełnego zestawu.
Kryteria wyboru scenariuszy do automatyzacji w pipeline
Praktyczny sposób wyboru scenariuszy do testów CI można streścić w kilku krokach:
spisać najczęstsze ścieżki użytkownika (na podstawie logów, analytics, rozmów z biznesem),
pogrupować je według krytyczności (wysoka, średnia, niska),
Priorytetyzacja scenariuszy względem kosztu utrzymania
Po wstępnej selekcji przydaje się jeszcze jedno sito: koszt utrzymania scenariusza w czasie. Niektóre ścieżki są proste i stabilne, inne zmieniają się przy każdym sprincie i będą generować stały „podatek utrzymaniowy”.
Przy każdym kandydacie do automatyzacji w pipeline warto zadać kilka pytań:
jak często zmienia się UI/API wokół tego flowu,
czy scenariusz mocno zależy od danych (wysoce dynamiczne ID, tokeny, skomplikowane pre-kondycje),
czy jest prosty do odtworzenia w narzędziu load testowym (np. czyste REST vs. skomplikowane sekwencje WebSocket/streaming).
Jeśli scenariusz jest biznesowo średnio ważny, a jednocześnie bardzo kapryśny technicznie, zwykle taniej jest uruchamiać go tylko w dedykowanych kampaniach. W CI lepiej trzymać się ścieżek stabilnych, które nie wymagają ciągłego „dokręcania śrubek” przy każdym refaktorze frontendu czy kontraktu API.
Łączenie testów obciążeniowych z innymi typami testów w pipeline
Testy wydajności nie muszą żyć w próżni. Dobry efekt daje lekkie spięcie ich z testami integracyjnymi czy kontraktowymi. Przykładowo:
po przejściu testów API (kontrakty) można z tych samych definicji endpointów generować scenariusze load testów,
po sukcesie smoke testów funkcjonalnych odpalać krótki performance smoke na tych samych endpointach, aby wykryć regresję „zaraz po deployu na środowisko testowe”.
Takie podejście zmniejsza koszt utrzymania, bo jeden opis ścieżki użytkownika służy kilku typom testów. W wielu zespołach dobrze sprawdza się prosty schemat: najpierw testy jednostkowe, potem API/kontrakty, następnie krótkie smoked, a na końcu lekki load test regresyjny. Jeśli którykolwiek z etapów „zapali się na czerwono”, kolejne nie są uruchamiane – oszczędza to czas i zasoby.
Separacja testów na różne gałęzie i typy buildów
Nie każdy commit zasługuje na pełny zestaw testów obciążeniowych. Aby nie przepalać budżetu, część zespołów stosuje prosty podział:
na gałęziach feature – tylko bardzo krótkie performance smoke (albo w ogóle brak performance w CI per-commit),
na gałęzi develop – pełniejszy, ale wciąż krótki zestaw testów obciążeniowych raz na jakiś czas (np. co merge lub raz dziennie),
na release/hotfix – pełny pakiet scenariuszy CI + dedykowany pipeline „perf-pre-release”.
Automatyczne warunkowanie kroków pipeline (np. uruchamianie testów obciążeniowych tylko przy zmianach w określonych modułach back-endu) jeszcze bardziej ogranicza koszty. Jeśli commit dotyka wyłącznie CSS czy tekstów na froncie, pełny load test najczęściej jest tylko zbędnym rachunkiem za zasoby.
Źródło: Pexels | Autor: Jakub Zerdzicki
Architektura: jak wpiąć testy obciążeniowe w istniejący pipeline CI/CD
Oddzielny stage „performance” w pipeline
Najprostszy i zwykle najtańszy do wdrożenia wariant to dodanie osobnego stage w pipeline, który uruchamia się po przejściu testów funkcjonalnych. Przykładowa sekwencja:
Taki stage może być konfigurowany jako obowiązkowy dla merge’u do głównej gałęzi, ale opcjonalny dla innych. W wielu systemach CI (GitLab CI, GitHub Actions, Jenkins) da się go włączyć tylko na wybranych branchach albo np. po oznaczeniu MR etykietą run-perf.
Dedykowane środowisko testowe dla performance
Kluczowy element architektury to miejsce, gdzie testy obciążeniowe uderzają. W idealnym świecie jest to oddzielne, lekkie środowisko, które:
ma własną bazę danych (choćby mniejszą),
ma możliwie podobną konfigurację do produkcji (limit replik, limity zasobów),
jest odizolowane od innych ciężkich procesów.
Jeżeli budżet nie pozwala na osobny, stale działający cluster, dobrą opcją jest tymczasowe środowisko (ephemeral environment) podnoszone tylko na czas testu. Może to być osobny namespace w Kubernetesie, osobna grupa maszyn na czas runu lub kontenery uruchamiane przez docker-compose. Po zakończeniu testów środowisko jest automatycznie usuwane, więc koszt jest powiązany z realnym użyciem.
Gdzie fizycznie uruchamiać generator obciążenia
Generator loadu (JMeter, k6, Gatling, Locust, itd.) nie musi żyć w tym samym miejscu, co aplikacja. Do wyboru są trzy główne warianty:
Agent CI jako load generator – najprostsze rozwiązanie: skrypt z testem uruchamia się na workerze CI. Dobre na start, ale przy wyższym ruchu agent może stać się wąskim gardłem.
Oddzielna maszyna / pod z narzędziem – pipeline tylko „odpala” test przez API (np. k6 Cloud, BlazeMeter, wewnętrzny serwis). Sam load generuje dedykowana infrastruktura, z którą CI łączy się zdalnie.
Wbudowany load w clusterze – np. osobny deployment k6 w Kubernetesie. Pipeline odpala job w tym samym clusterze, w którym działa aplikacja (łatwa sieć, mniejsza zmienność opóźnień).
Na początek warto zacząć od wariantu z agentem CI, a dopiero przy pierwszych oznakach braków wydajności (samego generatora) przenieść się na dedykowane środowisko. Dzięki temu nie inwestuje się zbyt wcześnie w „ciężką” infrastrukturę.
Przepływ danych: od uruchomienia testu do raportu
Żeby performance stage był użyteczny, pipeline musi nie tylko odpalić test, ale też:
zebrać surowe wyniki (logi, JSON, JTL, raporty HTML),
przeliczyć metryki potrzebne do decyzji pass/fail (percentyle, error rate),
zarchiwizować dane w sposób pozwalający na porównanie między buildami.
W prostym wariancie raporty można po prostu dołączyć jako artefakty joba w CI. Wygodniejszy, choć minimalnie droższy, jest eksport metryk do systemu typu Prometheus + Grafana lub do istniejącego APM. Pipeline może wysyłać metryki z testu jako osobny „service” i tam zestawiać je z baseline.
Integracja z narzędziami obserwowalności
Duży zysk przy niewielkim nakładzie daje spięcie load testów z monitoringiem aplikacji. W praktyce sprowadza się to do dwóch prostych kroków:
oznaczanie testów obciążeniowych osobnym tagiem / flagą (np. w nagłówku HTTP albo nazwie release’u),
budowa dashboardu w Grafanie / APM, który filtruje ruch „testowy” i pokazuje kluczowe metryki (latencja, CPU, GC, I/O).
Przy takiej konfiguracji inżynier nie musi ręcznie przeglądać logów z load generatora. Zamiast tego widzi, jak test przełożył się na realne zachowanie serwisu i czy w trakcie obciążenia nie pojawiły się nowe błędy lub wąskie gardła (np. wzrost czasu odpowiedzi bazy danych).
Wybór narzędzi do automatycznych testów obciążeniowych a budżet i czas
Podstawowe kryteria wyboru narzędzia
Na rynku jest mnóstwo rozwiązań – od prostych CLI po rozbudowane platformy SaaS. Z punktu widzenia zespołu, który liczy budżet i czas, przydatne są konkretne kryteria:
Koszt licencji i infrastruktury – czy narzędzie jest open source, czy wymaga płatnej subskrypcji, jak dużo zasobów zjada przy typowym teście.
Łatwość integracji z CI – wsparcie dla Docker, gotowe pluginy do Jenkinsa/GitLaba/GitHuba, sensowny tryb non-GUI.
Język i format scenariuszy – czy zespół umie pisać w danym języku (JS dla k6, Scala dla Gatlinga, Python dla Locusta), czy narzędzie wspiera declarative YAML/JSON.
Wsparcie dla protokołów – HTTP/HTTPS zwykle wystarczy, ale czasem potrzebne są WebSockets, gRPC, MQTT itp.
Na etapie startu nie ma sensu przepłacać za wyszukane funkcje, z których zespół nie skorzysta przez najbliższe miesiące. Lepiej użyć prostego narzędzia, które „wejdzie” w pipeline w ciągu tygodnia, niż budować idealną platformę pół roku.
Popularne narzędzia open source – co pasuje do CI
Wśród darmowych rozwiązań prym wiodą:
k6 – lekki, skryptowany w JavaScript, świetnie integruje się z Dockerem i CI. Bardzo dobry wybór na start, szczególnie do HTTP/REST.
JMeter – klasyk z bogatym ekosystemem. Wersja bez GUI (non-GUI) nadaje się do CI, ale wymaga sensownej konfiguracji, żeby nie paliła niepotrzebnie CPU.
Gatling – scenariusze w Scali lub DSL; mocny w integracji z pipeline’ami JVM, ale wymaga znajomości ekosystemu.
Locust – Python, co dla wielu zespołów jest atutem. Prosty do wdrożenia, dobry do eksperymentów.
Jeśli zespół używa głównie JavaScript/TypeScript, k6 zwykle będzie najtańszy w utrzymaniu (wszyscy rozumieją skrypty). W środowiskach mocno javowych Gatling lub JMeter w wersji headless są rozsądnym wyborem. Pythonowe zespoły dobrze odnajdują się w Locuście.
Kiedy ma sens rozważać komercyjne platformy
Płatne rozwiązania (cloudowe load generatory, APM z modułem load testing, platformy „wszystko w jednym”) mają sens dopiero wtedy, gdy:
zewnętrzna skala ruchu jest na tyle duża, że własny generator wymagałby sporej inwestycji w infrastrukturę,
zespół nie ma czasu budować własnych dashboardów, a potrzebuje rozbudowanego raportowania „na wczoraj”,
firmowe polityki bezpieczeństwa pozwalają na wysyłanie ruchu testowego przez chmurę zewnętrzną.
Dobrym kompromisem jest model hybrydowy: narzędzie open source jako baza + okazjonalne kampanie z użyciem platformy cloud (np. przed dużą premierą), gdy trzeba wygenerować większe obciążenie niż to, na które pozwala infrastruktura CI.
„Tani” stack na początek
Dla większości zespołów rozsądny, budżetowy start może wyglądać tak:
k6 lub JMeter w kontenerze Docker jako generator obciążenia,
prosty skrypt shell/Makefile uruchamiany przez CI,
raporty w formie JSON/HTML jako artefakty pipeline’u,
opcjonalnie Prometheus + Grafana podpięte do aplikacji, bez integracji bezpośrednio z narzędziem load testowym.
Taki zestaw zwykle można uruchomić w ciągu kilku dni i od razu zyskać pierwsze sygnały o regresjach, zamiast przez miesiące projektować „docelową” platformę performance.
Projektowanie lekkich scenariuszy testów wydajności do CI
Prosty model obciążenia zamiast kopiowania produkcji 1:1
Typowy błąd na starcie to próba odtworzenia pełnego profilu ruchu produkcyjnego w codziennym pipeline. Zamiast tego lepiej zaprojektować model uproszczony, który obejmuje:
kilka dominujących ścieżek użytkownika,
stałą, stosunkowo niewielką liczbę wirtualnych użytkowników,
jasno określony czas ramp-up i trwania testu.
Taki scenariusz nie pokaże absolutnej pojemności systemu, ale szybko wykryje, że nowy release pogorszył czas odpowiedzi lub zwiększył liczbę błędów przy typowym, umiarkowanym ruchu.
Ograniczanie liczby zależności i przygotowania danych
Im więcej kroków przygotowawczych wymaga scenariusz, tym bardziej rośnie koszt jego utrzymania. Przy projektowaniu lekkich testów warto minimalizować:
zależności od zewnętrznych systemów (np. integracje z systemami płatności można stubować),
skomplikowane przygotowanie danych (tworzenie wielu encji, ręczne czyszczenie bazy po teście),
operacje, które trudno zrównoleglić i mogą same w sobie stać się wąskim gardłem (np. wielokrotne logowanie z tymi samymi poświadczeniami).
Jedna z praktycznych technik to przygotowanie małego, powtarzalnego zestawu danych testowych (np. kilku kont użytkowników, kilku produktów) i używanie go w każdym teście zamiast dynamicznego tworzenia danych od zera.
Parametryzacja scenariuszy pod różne tryby uruchomienia
Dobry scenariusz da się łatwo „przestroić” w zależności od tego, czy uruchamiany jest w CI, czy w dłuższej kampanii. Służą do tego parametry, które można przekazywać z pipeline’u, np.:
