Cześć! Pierwszy techniczny artykuł w Cesarstwie-Dev, i od razu coś ekstra! Połączenie dwóch tematów, które są bardzo bliskie memu sercu – integracje z zewnętrznymi systemami oraz testy! To co? Zaczynajmy!

Dla kogo?

Wpis jest skierowany dla wszystkich, którzy znają podstawy jakiegoś języku obiektowego. Przydatna będzie również podstawowa znajomość interfejsu WebApi oraz protokołu HTTP. Jednak nawet bez tych podstaw będzie można zaczerpnąć wiedzę z tego artykułu, gdyż omawiane w nim treści powinny być w miarę samo-opisujące. Dla doświadczonych osób wpis ten może pokazać nowy sposób na robienie znanych już rzeczy. Może też stanowić bodziec do postawienia kolejnego kroku. TDD Wam coś mówi? Warto doczytać!

Dla osób na poziomie podstawowym umieszczam króciutki słownik pojęć:

  • Sprint – ustalone okno czasowe, w czasie którego powstaje zaplanowana część produktu
  • Backlog – miejsce, w którym przechowywane są zadania,
  • API – zbiór reguł ściśle opisujący, w jaki sposób można skomunikować się z wybranym programem
  • Kod produkcyjny – kod, który zawiera logikę potrzebną do działania aplikacji
  • Testy – kod, który sprawdza poprawność kodu produkcyjnego
  • Integracja – sposób, w jaki jeden system potrafi komunikować się z innym

Poznajemy API Narodowego Banku Polskiego

Zaczynamy nowy sprint, zadań przypisanych do nas wciąż brak. Wchodzimy więc w backlog i widzimy tam zadanie, które wydaje się być idealnym dla nas. Integracja z API NBP. Szybki podgląd ich strony i mamy pobieżny ogląd tego interfejsu. Są dwie możliwości pobrania kursów walut:

  1. Zapytania o kompletną tabelą A, B bądź C (czym się różnią przeczytasz tutaj)
  2. Zapytania o pojedynczą walutę z wybranej tabeli.

Jak widać, jest wiele różnych parametrów, które możemy zastosować. My skupimy się na najprostszym rozwiązaniu, czyli wyłącznie podstawowym zapytaniu pobierającym kurs pojedynczej waluty. Do dzieła!

Zacznijmy od testu

Krótki komentarz na początek – jestem świadomy niedoskonałości poniższego kodu. Ma on wyłącznie przekazać zamysł, który towarzyszy całemu procesowi. Uproszczenia stosowałem w celu uzyskania jak największej przejrzystości.

Pierwszy test będzie bardzo prosty. Tworzy on nowego klienta HTTP oraz sprawdza, czy pod żądanym adresem rzeczywiście znajduję się jakiś serwis. Zacznijmy od sprawdzenia amerykańskiego dolara w tabeli A.

Gdy przekonaliśmy się, że test przechodzi, warto sprawdzić co dany serwis nam zwraca. My spodziewamy się JSON’a, więc napiszmy odpowiedni test!

I ten test przeszedł bez żadnych komplikacji. Pisząc ten test zdecydowałem się na wydzielenie osobnej metody, która pozwoli mi w prosty sposób pisać kolejne testy. Czyżbyśmy znaleźli podwaliny pod integrację z nowym API?

Co z poprawnością danych?

Kolejny test sprawdzi, czy zwracane dane są zgodne z oczekiwanymi. Wpierw jednak musimy poznać strukturę odpowiedzi. Jak? Nic prostszego! Wystarczy dopisać Console.WriteLine(contnet) i przeczytać! Ja zastosuję jednak narzędzie Postman.

Napiszmy więc klasę, która będzie odpowiadała powyższym danym w formacie JSON oraz test, który sprawdzi czy sprasowana przez nas odpowiedź zawiera prawidłowe dane.

Jak wszystko dobrze nam idzie! Praktycznie skończyliśmy, a ledwo zaczęliśmy. Jakie to może być piękne i proste. Zapomnieliśmy jednak o jednej rzeczy! A co jeśli dane różnią się dla różnych tabel? I w rzeczywistości tak jest, dane z różnych tabel zwracają różne rezultaty. Mamy teraz trzy opcje

  1. Idziemy do lidera, i pytamy z którą tabelą chce się zintegrować. Ale co jeśli powie że wszystkimi?
  2. Uwzględniamy w jednym modelu wszystkie pola. W skrócie mówiąc, to jest zły pomysł.
  3. Wydzielimy z naszego serwisu trzy metody, zwracające trzy różne klasy. Wtedy każdy będzie wiedział jakich danych oczekiwać, jak i nikt nie pomyli się w nazwie tabeli!

W obecnej chwili możemy dopisać kolejne testy dla każdej z tabel, na pewno nie będzie to strata czasu. Pozwoli nam lepiej poznać API, oraz stworzyć pewnego rodzaju dokumentację całej integracji. Ostatecznie, będziemy w stanie wydzielić fragmenty kodu odpowiadające za integrację z zewnętrznym systemem oraz opakować je w interfejs, który może na przykład wyglądać następująco (jednak warto pomyśleć nad lepszym nazewnictwem!). Pełny kod zaimplementowanego serwisu znajduje w kolejnym wpisie, do którego serdecznie zapraszam. Dostępny jest tutaj.

Podsumowanie

Jak widać na powyższym przykładzie, proces integracji poprzez testy jest dość szybki, pozwala wyłapać dużo błędów na wczesnym etapie implementacji, stanowi również pewien rodzaj dokumentacji takiej integracji. Dużo tych plusów, prawda? I ciężko tak naprawdę znaleźć wady takiego sposobu. Nawet dla ludzi, którzy uważają że testy to strata czasu, jest to świetne rozwiązanie! W krótkim czasie mogą zarówno otrzymać kod produkcyjny, jak i testy sprawdzające poprawność integracji. Dwie pieczenie na jednym ogniu!

Mam nadzieję, że podobało się Wam czytanie tego artykułu tak samo jak mi jego przygotowywanie!

Dodatkowo, skoro dotarliście aż tutaj, to mam nadzieję że zawitacie na dłużej w moim nowym projekcie Cesarstwo-Dev, które początek opisuję tutaj!

I już na sam koniec, nuta do odsłuchania dla chętnych


2 Komentarze

Architektura heksagonalna w C# - Cesarstwo Dev Techniczne · 2020-09-29 o 09:54

[…] mogliście się trochę z niego nauczyć. Jeśli tak jest, to może chcecie sprawdzić wpis na temat integrowania z zewnętrznym systemem za pomocą testów? Niezależnie od wszystkiego – bardzo Wam dziękuję za uwagę! Do usłyszenia w kolejnym […]

dotnetomaniak.pl · 2020-09-17 o 20:56

Integracja z zewnętrznym API przy użyciu testów

Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *