Testowanie aplikacji korzystającej z zewnętrznego API

0

Cześć.

Chcę napisać skrypt konsolowy do obliczania m.in. wartości portfela (akcje, papiery wartościowe, podatki itp.).
Chcę skorzystać z zewnętrznego API.
Pytanie jak powinny wyglądać testy takiej prostej aplikacji konsolowej?

Przy zamokowaniu zewnętrznego API nie ma pewności, że ono się nie zmieni, więc chyba nie tędy droga.
Testując metody niewykorzystujące zewnętrznego API (testy jednostkowe i integracyjne) nie mamy przecież pewności, że aplikacja zadziała poprawnie.

0

Powinieneś mockować wywołania do API i założyć, że działa ono poprawnie.
Tj. powinieneś testować swoją aplikację, nie cudze API.

0

I believe there should be 2 level of verifications we need to do when we interface with an external API:

API verification: verify that the API works according to its specs and/or our understanding

App functionality verification: verify that our business logic works according to the expectation to the API that passes API verification
In our case, we use a mock API together with real and mock API verification.

Przy zmokowanym API można testować jednostkowo własny kod, ale chyba pozostaje jeszcze kwestia sprawdzenia czy samo API zwraca "prawdziwe" dane... Pytanie jak to stwierdzić? Kolejne API?

Dane takie jak np. kursy akcji to tzw. real time data i stąd pytanie jak po swojej stronie stwierdzić, że są one poprawne.

0

Powtórzę: nie powinieneś testować czyjegoś API - to jest ich robota, aby API zwracało poprawne dane.

Podobnie jak nie powinieneś testować kodu frameworka, ORMa czy czegokolwiek 3rd-party (poza jakimiś specyficznymi przypadkami) - traktujesz to jak czarną skrzynkę, która działa.

0

Ok, a co da nam pewność, że zachowanie tego API się nie zmieni?
I czyja to rola? Czasami umowy i specyfikacje nie wystarczają.

0

Zwyczajowo API są wersjonowane i jeśli wychodzi jakiś breaking-change, API dostaje nową wersję, a co za tym idzie - nowy endpoint (http://foo.com/api/v1/, http://foo.com/api/v2/ itd.).

0

Nie nowy endpoint, tylko klient określa wersję api w nagłówku http, przynajmniej jeśli chodzi o api restowe

0
Patryk27 napisał(a):

Zwyczajowo API są wersjonowane i jeśli wychodzi jakiś breaking-change, API dostaje nową wersję, a co za tym idzie - nowy endpoint (http://foo.com/api/v1/, http://foo.com/api/v2/ itd.).

Brzmi jak bardzo dobra praktyka, ale niewszędzie tak jest.
Swoją drogą w świecie mikroserwisów piekłem musi być apdejtowanie i podnoszenie wersji multum zależności; no chyba że są jakieś utarte sposoby na to.

0
Czarny Krawiec napisał(a):

Nie nowy endpoint, tylko klient określa wersję api w nagłówku http, przynajmniej jeśli chodzi o api restowe

To, czy to będzie nagłówek, query string czy path, zależy od autorów API.

0

My mieliśmy do czynienia z API które miało dość wysokie failure rate w środowisku testowym, do tego nie zawsze wiadomo było czy to co chcemy przetestować będzie w danej chwili dostępne (bardzo specyficzne oferty promocyjne) i stosowaliśmy proxy które nagrywało ruch. Dzięki temu testy akceptacyjne szły o wiele szybciej (całość z około 12h zeszła w okolice pół godziny), po kilku sesjach testowych mieliśmy nagrane tyle przypadków że nawet gdyby tymczasowo to API padło, to mogliśmy kontynuować prace. Ten nagrany ruch był wywalany raz na tydzień więc o zmianach (nie zawsze zapowiedzianych) dowiadywaliśmy się prawie od razu. Do testów stricte integracyjnych pomiędzy komponentami naszego systemu zakładaliśmy całkowitą poprawność i requesty były hardcodowane w mockach tych serwisów. Tylko testy akceptacyjne (nasz system był postawiony z proxy zamiast mocków) szły przez to proxy. Ewentualne zmiany propagowało się do testów integracyjnych (w mocki serwisów). Raz na tydzień testy szły też bez mocków ani proxy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1