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

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

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.

Fine Code Coverage

 Bawiąc się moim testowym projektem WinFormsCrud w pewnym momencie postanowiłem sprawdzić sobie jakie mam pokrycie kodu testami jednostkowymi. O ile wiedziałem, że dla samego projektu WinForms będzie zero (bo do tego projektu jeszcze nie dołożyłem testów) o tyle dla pozostałych projektów byłem zainteresowany ile % wyjdzie. 

Samo visual studio 2022 nie ma tego feature w standardzie, o tyle z pomocą przyszedł mi stackoverflow.com który poinformował mi, że dla Visual Studio 2022 Community istnieje darmowy tool pozwalający to sprawdzić, czyli FineCodeCoverage2022 

Sprawdzilem sobie ten tool i on faktycznie działa.

Wiadomo, zawsze mogło być lepiej, natomiast w tym momencie najważniejsze że tool jest darmowy i działa.

FluentAssertions

FluentAssertions to jest paczka NuGet rozszerzająca sposób pisania testów jednostkowych w .NET. W praktyce dostajemy dodatkowe metody rozszerzające służące do testowania. Ja wykorzystywałem to razem z biblioteką xUnit ale nie jestem pewny czy musi to być koniecznie xUnit czy też może być inna biblioteka testów jednostkowych. Paczka FluentAssertions dodaje nam możliwość wykonywania assercji w "płynny" sposób, np. zamiast pisać:

string username = "dennis";

Assert.Equal("jonas", username);

możemy napisać:

string username = "dennis";

username.Should().Be("jonas");

Oczywiście biblioteka ma więcej metod i jest znacznie bardziej płynna i zawiera znacznie więcej sposób rozszerzenia i testowania. 

Strona projektu: https://fluentassertions.com/ 

Paczka NuGet: https://www.nuget.org/packages/fluentassertions/

Edycja: Od wersji v8 biblioteka będzie płatna dla użytkowników komercyjnych, czyli nie będzie już można sobie z niej swobodnie korzystać w zastosowaniach komercyjnych jak do tej pory.

Testowanie ConfigurationManager (xUnit, FakeItEasy)

Tworząc testy jednostkowe ważne jest, aby testy działały bardzo szybko, oraz niezależnie od zewnętrznych zasobów, takich jak np. web service, dostęp do plików itp. Mówi o tym, m.in. Roy Osherove podczas swoich szkoleń, np. Understanding Test Driven Development

Jednym z takich zewnętrznych zasobów dla aplikacji internetowych, jest plik konfiguracyjny web.config. Przykładowy sposób, jak skutecznie zastosować DI oraz testy jednostkowe dla tego rozwiązania pokazuje na swoim blogu KAZI MANZUR RASHID. Niestety dla mnie, Kazi pokazuje to z wykorzystaniem "Mock", natomiast Ja, pod wpływem postów Macieja Aniserowicza jako narzędzie 'mockujące' postanowiłem wykorzystywać FakeItEasy.  Poniżej prezentuję działające rozwiązanie wykorzystujące bibliotekę FakeItEasy.

Ponieważ zmieniam tylko bibliotekę 'Mock' na "FakeItEasy' to podstawowe klasy, pozostały takie same, jak w kodzie Kazi Manur'a

    public interface IConfigurationManager
    {
        NameValueCollection AppSettings
        {
            get;
        }
        string ConnectionStrings(string name);
        T GetSection<T>(string sectionName);
    }
    public class ConfigurationManagerWrapper : IConfigurationManager
    {
        public NameValueCollection AppSettings
        {
            get
            {
                return ConfigurationManager.AppSettings;
            }
        }
        public string ConnectionStrings(string name)
        {
            return ConfigurationManager.ConnectionStrings[name].ConnectionString;
        }
        public T GetSection<T>(string sectionName)
        {
            return (T)ConfigurationManager.GetSection(sectionName);
        }
    }

Aby pokazać bardziej realistyczny przykład użycia, utworzyłem klasę BL (Business Logic), która do swojej pracy wykorzystuje dane, pobrane z web.config. Założyłem również, że plik web.config posiada wpis o nazwie customAppSetting z wartością "test".

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
public class BL
{
    private readonly IConfigurationManager configuration;
public BL()
{
        this.configuration = new ConfigurationManagerWrapper();
}
    public BL(IConfigurationManager configuration)
    {
        this.configuration = configuration;
    }
    public string GetAppSetting(string customAppSettingName)
    {
        string customAppSetting = configuration.AppSettings[customAppSettingName];
        //TODO: some business logic
        return customAppSetting;
    }
}

Praktyczne wykorzystanie klasy BL przez solucję produkcyjną:

    private void ProductionWebConfig()
    {
        BL businessLogic = new BL(new ConfigurationManagerWrapper());
        string customAppSetting = businessLogic.GetAppSetting("customAppSetting");
    }

Praktyczne wykorzystanie klasy BL przez bibliotekę testującą:

    [Fact]
    public void GetAppSetting_PositiveString_StringTest()
    {
        var customAppSetting = new NameValueCollection { { "customAppSetting", "test" } };
        IConfigurationManager fakeConfiguration = A.Fake<IConfigurationManager>();
        A.CallTo(() => fakeConfiguration.AppSettings).Returns(customAppSetting);
        BL bl = new BL(fakeConfiguration);
        string fakeString = bl.GetAppSetting("customAppSetting");
        string realString = "test";
        Assert.Equal(fakeString, realString);
    }

Selenium - software testing framework for web applications

Przeglądając wykład Grzegorza Dudy podczas konferencji confitura 2012 pt. From Busy to Effective Developer odkryłem fajne, nowe narzędzie, które zademonstrował Grzegorz. Narzędzie nazywa się selenium i służy do testowania stron internetowych. O ile, nie wgłębiałem się szczegółowo w API tego narzędzia, to jego podstawowa funkcjonalność, dostępna jako plug-in do przeglądardki firefox służy do nagrywania/reprodukcji schematu poruszania się po stronie internetowej.

Czasami zdarza się bowiem, że aby odtworzyć błąd, trzeba się 'przeklikać' przez wiele formularzy (i dopiero wtedy podpiąć debugger). W takich właśnie momentach przydaje się Selenium. Za pierwszym razem, przeklikując się przez formularze włączamy opcję 'rejestrowania', a przy nast., okazji, gdy potrzebujemy wykonać identyczną operację tylko włączamy opcję odtwarzania poprzednio zapisanego scenariusza testowego.

Narzędzie dostępne jest na licencji Apache 2.0 więc spokojnie możemy z niego korzystać, a nawet rozwijać.