Testy automatyczne serwisu

Mam serwis który wystawia endpoint na który klient wysyła jakieś dane. Ze względu na to że proces nie jest w pełni automatyczny odpowiadamy klientowi 200 (OK) świadczącą o tym że przyjęliśmy jego żądanie. Robimy całą swoją magie po czym wyniki operacji wysyłamy po HTTP na jego endpoint a on odpowiada jakimś prostym payloadem z ID, statusem, etc. My to zapisujemy do bazy i nic poza tym serwis nie robi. Działa to na PRODzie ale też ten sam serwis działa na QA tak żeby klient mógł sobie wysyłać testowe requesty do nas.

Załóżmy że teraz chcielibyśmy napisać jakieś testy automatyczne (dodatkowy serwis) który będzie wysyłał co jakiś czas requesty do serwisu który robi całą tę magię ale oczywiście nie chcemy po przetworzeniu żądania wysyłać żadnych requestów do klienta.

W jaki sposób zrobić to prawidłowo? Mogę w kodzie dodać haki w stylu jeśli rozpoznam że żądanie po chodzi z testów to nie wysyłaj wyników do klienta ale moim zdaniem to słabe rozwiązanie.

Jakieś sensowne propozycje?

Może feature flag? Ale jaki jest sens wystawiać inny serwis na QA, a inny na prodzie?

Nie testuj na PRODZie? o_O Stawiacie ten serwis na jakimś testowym środowisku i konfigurujecie ten callback URL na inny testowy serwer i tyle. W praktyce normalnie robi sie tak, ze to request usera zawiera callback URL, dzięki czemu jak klient zmieni URLa to nie trzeba nic robić.

iksde napisał(a):

Może feature flag? Ale jaki jest sens wystawiać inny serwis na QA, a inny na prodzie?

Żaden bo nie chce tego robić ponieważ nie chce mieć żadnych różnic pomiędzy PROD a QA (poza oczywiscie deweloperską).

Shalom napisał(a):

Nie testuj na PRODZie? o_O Stawiacie ten serwis na jakimś testowym środowisku i konfigurujecie ten callback URL na inny testowy serwer i tyle. W praktyce normalnie robi sie tak, ze to request usera zawiera callback URL, dzięki czemu jak klient zmieni URLa to nie trzeba nic robić.

Gdzie ja napisałem ze testuje coś na prodzie?
Mam 2 środowiska (tzn jest ich więcej ale skupmy się na tych dwóch). Produkcyjne na którym działa instancja z której klient na co dzień korzysta i QA na którym działa wersja deweloperska do której również klient ma dostęp ponieważ jest to zewnętrzny klient i pozwalamy mu testować integracje między naszymi serwisami. Nic na prodzie nie chce wiec testować tylko na QA instancje która klient również odpytuje. Twój pomysł oczywiście ma sens przy założeniu ze wymusze od klienta aby zmienił implementacje swoich requestow bo aktualna nie zawiera urla na który mam mu odpowiedzieć natomiast poki co nie jest to możliwe. Sam pomysł jednak przyznaje ze ciekawy z tym ze w tym przypadku niemożliwy do realizacji.

No to postaw sobie jeszcze jedno środowisko testowe, tym razem takie które nie ma hardkodowanego URLa do klienta. Przykro mi ale instancja z której korzysta klient, nawet jeśli nie jest stricte prodem, to nadal jest jakimś UATem czy czymś takim i testowanie na nim to nadal słaby plan.

Monitoring is new testing :) skonfigurujcie sobie czujki tak, żeby zespół albo SRE wiedzieli czy to działa.

Testy automatyczne spoko, ale na osobnym środowisku - wpp. zaśmiecisz proda jakimiś testowymi danymi, pójdzie to do metryk i raportów itd. Zrobi się niezły syf.

Nie oznacza to oczywiście, aby nie testować na produkcji w ogóle. Można to robić jakimś testem A/B czy za pomocą feature flag - ale to zupełnie odrębny temat.

Przecież zdecydowana większość takich środowisk ma jakąś konfigurację.
Można dodać do konfiguracji:

• wysyłaj odpowiedź := {true, false}
• URL odpowiedzi := {produkcja.pl/api, localhost/devnull}

Jeżeli to jest wtórne wobec wcześniejszych odpowiedzi, to przepraszam.