Jak symulować interfejs API REST?

Pracuję nad nowym projektem, który będzie wyszukiwał dane z interfejsu API REST innej firmy. Odnosi się to do sportowego pliku danych w czasie rzeczywistym, więc kanał działa tylko wtedy, gdy gra rzeczywiście się odbywa.

Chociaż firma zewnętrzna zapewnia dobrą dokumentację (XSD itp.), Nie ma możliwości symulowania rozgrywki, więc aby przetestować kod napisany na podstawie tego interfejsu API, musiałbym poczekać na faktyczną rozgrywkę.

Moim jedynym wyjściem jest napisanie kodu do samodzielnej symulacji gry, ale wydaje się, że to dużo pracy. Jak byś do tego podszedł?

Jest to idealny przypadek użycia dla fałszywego obiektu . Istnieją kpiące biblioteki dla każdego popularnego języka. Chcesz wyśmiewać obiekt, który udostępnia odpowiedzi usługi REST w celu zwrócenia danych testowych. Możesz ręcznie wygenerować dane testowe lub zebrać je z poprzednich połączeń z systemem na żywo.

Poczekaj, aż gra się rozpocznie. Przechwytuj każde zdarzenie z kanału. Napisz symulator, który odtworzy zdarzenia we właściwym czasie. Voila, masz symulator kanału z prawdziwymi danymi.

Polecam napisanie własnego symulatora. Możesz go użyć do przetestowania wszelkiego rodzaju scenariuszy;

• Serwer akceptuje połączenie, ale nie odpowiada
• Limit czasu serwera
• Serwer odsyła odpowiedzi śmieci itd.

Kiedy robiłem to w przeszłości, użyłem „specjalnych” wartości w komunikatach żądania, aby zachęcić symulator do zrobienia tego, czego potrzebuję. Umożliwia to także przeprowadzanie kompleksowych testów bez wychodzenia poza środowisko programistyczne.

Edycja: Na przykład, jeśli Twój projekt przesyła XML do usługi innej firmy, żądanie może obejmować np <value>50.00</value>. Symulator można kodować (lub, lepiej, skonfigurować), aby 50,00 => eksplodować, 60,00 => śmieci, 70,00 => ścisłe połączenie i tak dalej. Chodzi o to, że zachowanie symulatora zależy od jego danych wejściowych, które kontrolujesz w każdym przypadku testowym.

Biorąc pod uwagę, że prawdopodobnie bukmacher udostępnia pewne przykładowe dane (które można zapisać na etapie integracji), radzę zorganizować te kanały w następujący sposób:

• Lista wydarzeń
• Aktualizacje zaplanowanych wydarzeń
• Aktualizacje kursów
• Wyniki

Prawdopodobnie dostawca oferuje 2 rodzaje aktualizacji: Push (POST) i Pull (GET).

W tym momencie powinieneś

1. Utwórz prosty serwer, który po prostu obsługuje żądania GET, dzięki czemu programiści mogą opracowywać algorytmy.
2. Utwórz automatyzację, aby zarządzać przesyłaniem tych samych informacji, a tym samym obciążać system.

Zarządzaj rozwojem i testowaniem

Bez wchodzenia w szczegóły technologii, która ma być używana, otrzymujesz mini-serwer , który odpowiada tylko na 4 adresy URL (lub te niezbędne w zależności od tego, co oferuje dostawca), oraz usługę mini-push .

Bardzo dobrą rzeczą, o której należy pamiętać podczas pracy z „mini-serwerem”, są procedury obsługi protokołu HTTP. Utworzenie serwera na porcie 80 jest bardzo proste i rozwiązuje problem. Musisz upewnić się, że wprowadziłeś wszystkie informacje w odpowiedziach GET zgodnie z ofertą dostawcy (pozwoli to uniknąć problemów podczas wprowadzania do produkcji).

Osobiście zrobiłbym prosty serwer Perl lub taki sam, ale z Nodejs. W odniesieniu do wstrzykiwania danych, wystarczy zegar, który wywołuje przeglądarkę offline ( CURL , WGET )

I symulowane REST API, za pomocą kombinacji cucumberjs, phantomjs z ustawieniem serwera proxy 127.0.0.1 i zaczepiania node.js proces http-proxyi nocktam. CucumberJS nie jest ważną częścią, możesz napisać scenariusz testowy w dowolny sposób, reszta jest kluczem do symulacji. Jest w stanie wyśmiewać po prostu dane dopasowania-żądanie-zwrotu-dane, ale możesz również filtrować według wzorców i funkcji zwrotnej haka, aby uzyskać odpowiedź, dzięki czemu możesz symulować na dowolnym poziomie szczegółowości, którego potrzebujesz (w skrajnym przypadku kończąc na pełny serwer demonstracyjny, ale możesz to zrobić stopniowo).

Działa ładnie:

1. Phantomjs żąda identyfikatora URI.
2. Żądanie trafia do serwera proxy na porcie 127.0.0.1:port.
3. Twój node.js przetwarza proxy w sposób transparentny do przodu, używając http-proxy. Tak więc działa „normalne” ładowanie (strony, obrazy).
4. Jeśli zdecydujesz się przechwycić niektóre żądania (głównie API), wykorzystasz nockje.

W moim scenariuszu połączyłem go z testami js ogórka w tym samym procesie, więc poszło tak:

1. Przebiegi testowe.
2. Konfiguruje nockkpowanie HTTP dla testowanego scenariusza.
3. Ładuje stronę w phantomjs za pośrednictwem protokołu Selenium.

Reszta jest taka, jak pokazano wcześniej w tym akapicie (to znaczy, że to trochę cykl, ja jako biegacz testowy polecam phantomjs załadować stronę, która przekazuje mi wszystkie żądania z powrotem, i przesyłam je do sieci; lub przechwytuję jeśli jest to testowany interfejs API).