nBomber - testy wydajnościowe w .NET

Czasami biznes wymaga od nas przedstawienia raportu wydajności naszego API. Odpowiedni czas odpowiedzi lub ilość zapytań na sekundę może też być zdefiniowane jako element wymagań biznesowych wobec systemu który projektujemy lub którym zarządzamy. Możemy wtedy próbować pisać odpowiednie rozwiązania samemu, lub użyć gotowego rozwiązania. Takim gotowym rozwiązaniem napisanym w .NET i współpracującym z .NET-owymi bibliotekami testującymi (np. xUnitem) jest biblioteka nBomber. 

Linki:

https://nbomber.com/ - strona projektu

https://github.com/PragmaticFlow/NBomber - kod źródłowy na GitHub

pact.io - testy kontraktów (CDC)

 Aktualnie poszerzam moją wiedzę nt. tworzenia aplikacji i natrafiłem na nowy dla mnie temat, tj. testowanie kontraktów Consumer-Driven-Contract-Testing w skrócie zwane CDC. Do tego typu testów wykorzystywane jest rozwiązanie pact.io nt. z wtyczką dot-netową Pactify

Same testy polegają na stworzeniu w JSON "kontraktu" którego oczekuje konsument, a następnie samoistne odpytywanie endpointów czy oczekiwany kontrakt jest cały czas dostarczany. W tego typu testach skupiamy się na zmiennych oraz typach danych, a nie na samych wartościach, tzn. bardziej nas interesuje czy endpoint nadal posiada zakładane pola z zakładanymi typami danych niż faktyczne wartości tych pól.

Linki:

https://docs.pact.io/ - strona projektu 

https://github.com/snatch-dev/Pactify - wtyczka .netowa

onetimesecret.com

Czasami zdarza nam się prośba o wysłanie do kogoś jakiegoś hasła albo dyskretnej wiadomości, która po przeczytaniu powinna zostać usunięta. Czasami stosuje się do tego Teams, gdzie po przeczytaniu wiadomość jest usuwana z chatu. A co jeśli chcemy wysłać dyskretną wiadomość do kogoś, kto nie ma Teamsów? Tutaj z pomocą przychodzi strona onetimesecret.com , gdzie możemy wpisać naszą wiadomość, którą odbiorca za pomocą specjalnie wygenerowanego linku będzie mógł wyświetlić tylko raz. Wygenerowany przez nas link będzie mógł zostać odczytany tylko raz, co (przynajmniej w teorii) powoduje że nawet jeśli ktoś w przyszłości wykradnie skrzynkę pocztową naszą lub adresata naszej wiadomości to (przynajmniej w teorii) nie powinien poznać hasła przez nas przekazanego.

Strona może nie jest idealna, ale zawsze to kolejny kamyczek do ogródka zwanego bezpieczeństwem. 

WebMotions.Fake.Authentication.JwtBearer

 Nowy .net 8 daje nam bardzo fajną możliwość wykonywania testów integracyjnych naszych aplikacji webowych przy pomocy klasy WebApplicationFactory. Tego typu testy mogą się odbywać zarówno na faktycznej aplikacji jak i częściowo podmienionej, np. możemy sami podmienić niektóre serwisy, a inne zostawić takie jak były. Możemy zmienić bazę danych, na której mają się wykonywać testy itp. Bardzo fajne narzędzie choćby  po to, aby mieć pewność co finalnie wychodzi z naszej aplikacji. 

Czasami jednak potrzebujemy mieć aplikację z uwierzytelnieniem, tj. autoryzacją. Przykładowo przy pomocy JWT token. Oczywiście możemy pisać pełny kod od początku tak, aby łatwo się to podmieniało lub aby serwis tworzący tokena poprawnie zwracał go zarówno dla projektu z API jak i dla projektu z testami, ale czasami może się zdarzyć, że trafimy do istniejącego projektu, w którym następuje uwierzytelnienie w zewnętrznym serwisie do którego nie mamy dostępu, a przy okazji nie chcemy od samego początku przebudowywać całej aplikacji (refaktor powinien się odbywać ewolucyjnie, a nie rewolucyjnie). W takich sytuacjach z pomocą przychodzi nam paczka nugetowa: WebMotions.Fake.Authentication.JwtBearer 

Dzięki tej paczce w naszym BaseTestController możemy stworzyć metodę autoryzacji:

            dynamic data = new ExpandoObject();

            data.sub = Guid.NewGuid();

            data.role = new [] {"sub_role","admin"};

           Client.SetFakeBearerToken((object)data);

gdzie Client to jest obiekt klienta tworzony przez WebApplicationFactory w metodzie "WithWebHostBuilder(builder => {}).CreateClient();

Później możemysię to tych Claimsów odwołać w dowolnym miejscu aplikacji poprzez implementację interfejsu IHttpContextAccessor ,który możemy wstrzyknąć np. do naszej testowej implementacji ISecurityService (czy jaki tam będziemy mieli dowolny inny interfejs w naszej aplikacji odpowiedzialny za obsługę uwierzytelnienia).

Kod źródłowy dostępny na https://github.com/webmotions/fake-authentication-jwtbearer z licejcją MIT więc możemy to komercyjnie zastosować. Dzięki tej paczce, możemy sobie "zasymulować" autoryzację i podmienić jedynie serwis odpowiedzialny za autoryzację. Cała reszta aplikacji może pozostać tak jak była (sami decydujemy, którą część aplikacji chcemy testować tak jak jest, a którą chcemy symulować).

Linki

https://www.nuget.org/packages/WebMotions.Fake.Authentication.JwtBearer -  nuget

https://github.com/webmotions/fake-authentication-jwtbearer - github

https://licenses.nuget.org/MIT - licencja MIT

Humanizer

 Jak już wspomniałem w moim poprzednim poście oglądam sobie kurs "SOLID WebApi" od DevMentors i co jakiś czas wyłuskuję sobie z niego coś nowego. Tym razem wyłuskałem od nich paczkę NuGetową Humanizer  czyli gotowe rozszerzenie to zamiany stringów z jednej wersji na inną, np. z CamelCase na SnakeCase, albo ze SnakeCase na wyrazy rozdzielone spacją. Więcej przykładów jest na stronie projektu. To co warto wspomnieć, to kod źródłowy dostępny jest na githubie (open source), a sama paczka jest na licencji MIT, czyli można ją bez problemu używać również w komercyjnym oprogramowaniu.

Linki:

https://github.com/Humanizr/Humanizer - link do kodu źródłowego na GitHub z plikiem README oraz przykładami użycia.

https://www.nuget.org/packages/Humanizer/ - link do paczki na serwisie nuget

Shouldly NugetPackage

Oglądając kurs od DevMentors zauważyłem że używają oni pakietu Nugetowego Shoudly. Shouldy jest to kolejny pakiet który pozwala wykonywać testy jednostkowe w sposób bardziej płynny, czyli innymi słowy robi dokładnie to samo, co opisana przezemnie wcześniej paczka FluentAssertions.

Co warto wspomnieć, zarówno Shouldy jak i FluentAsserions mają w miarę przyjazne (z komercyjnego punktu widzenia) licencje. Shouldy ma licencję BSD-2, natomiast FluentAsserions posiada licencję Apache.

Linki:

https://docs.shouldly.org/ - strona projektu

https://www.nuget.org/packages/Shouldly - link do Shoudly na Nuget.

Wtyczka REST Client do Visual Studio Code

Kupiłem sobie kurs "Solidne Web API" od DevMentors, zacząłem sobie tego słuchać zauważyłem fajne narzędzie które pokazali. Chodzi o wtyczkę "Rest Client" dla edytora Visual Studio Code. Mianowicie możemy w bardzo prosty i łatwy sposób utworzyć sobie nowy plik tekstowy z rozszerzeniem .http i przy pomocy tej wtyczki testować nasze REST API niczym przy pomocy Postmana. Zaleta tego rozwiązania jest taka, że wszystko mamy zapisane w kodzie pod kontrolą systemu kontroli wersji (np. GIT).

Bardzo fajne i zgrabne podejście. Już mi się podoba.

Linki:

https://marketplace.visualstudio.com/items?itemName=humao.rest-client -> wtyczka

https://codewithandrea.com/tips/rest-client-vscode/ - tutaj przykładowe użycie

https://code.visualstudio.com/ -> visual studio code