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

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.

Rekruter

W czerwcu oraz na pocz. lipca miałem okazję uczestniczyć podczas rozmów kwalifikacyjnych na stanowisko młodszego programisty .NET (junior developer). Było to dla mnie spojrzenie na proces rekrutacji z tej nieco innej strony.  Jako, że od mojej opinii o kandydacie również nieco zależało, więc postaram się opisać moje wrażenia z tego procesu po "tej drugiej stronie".

Najpierw umieściliśmy ogłoszenie na kilku przeznaczonych do tego stronach oraz ulotki na kilku Warszawskich uczelniach. Po jakimś czasie, gdy pojawiła się grupa na fb o wdzięcznej nazwie netDevelopersPolandJobMarket to umieściłem tam nasze ogłoszenie z "widełkami płacowymi" oraz nieco większą ilością szczegółów nt. tego stanowiska (stos. technologia, zakres obowiązków itp. itd.).

A jak wyglądała sama rozmowa?
a) krótka, 5-20 min. rozmowa, podczas której my (Ja oraz dyrektor IT) opowiadaliśmy o firmie, naszym dziale IT, tym czym ewentualnie zajmował by się kandydat. Zadawaliśmy też kilka pytań nt. CV, które podesłał nam kandydat.
b) 30 min. codding test na laptopie w mojej obecności
c) "pytania z kartki", czyli mniej lub bardziej szczegółowe "pytania otwarte" nt. C#, .NET, MS SQL itp. itd.
d) ewentualna dalsza rozmowa z szefem IT

Zadania praktyczne były 4. Dwa z SQL oraz dwa z C#. Zadania były o zróżnicowanym stopniu trudności. Wydawało mi się, ze te z C# są trudniejsze, ale tylko do momentu, gdy jeden z kandydatów przyznał się, ze jedno z zadań mieli w SGGW na egaminie ;-)
To co mnie osobiście mocno zaskoczyło to... bardzo słaba znajomość T-SQL wśród kandydatów, którzy byli przepytywani. Dwie os., które "kumały cza-czę" zrobiły oba zadania w ok. 5-6 min. (mniej więcej ok 2-3 min. na zadanie). Niestety ponad połowa kandydatów nie zrobiła zadań z SQL w ogóle.

Z pytaniami "otwartymi" zazwyczaj było całkiem nieźle. Była to też okazja do "bardziej wnikliwego" porozmawiania z kandydatami (tymi co przeszli codding test). Podczas tej rozmowy, oprócz samych odp. na pytania, celem było też zwykłe poznanie kandydata. Tego, czy się interesuje technologią i w czym czuje się mocny, ale też, czy można z nim normalnie porozmawiać i czy da się z nim wytrzymać 8h*5 dni w tyg.

Jak ktoś przeszedł wszystkie etapy w miarę ok (codding test, pytania otwarte, sposób bycia) to zostawał na rozmowę z dyrektorem IT.

Wnioski:
a) 30 min. siedzenia i patrzenia jak ktoś koduje, to jednak zdecydowanie zbyt dużo zmarnowanego mojego czasu. Dobrze było by ten proces jakoś zautomatyzować, ale pozostając przy zadaniach praktycznych. Może jakieś codility, ale któreś z tych podst. poziomów trudności (ponieważ te wyższe zazwyczaj niewiele mają wspólnego z praktyką zastaną później w realnym życiu).
b) najlepszy możliwy kandydat, jaki nam się pojawił, przyszedł na rozmowe po umieszczeniu ogłoszenia o pracę na grupie fb (ogłsozenie z zakresem obowiązków, stos. technologią oraz widełkami płacowymi).

Nie testuj na serwerze testowym!!!

Ten oto wpis, to nic innego jak konkluzja z ost. kilku dni w pracy. I broń boże, nie wykonuj na tych danych, żadnych aktualizacji "notowań, kursu walut" ani innych "co nocnych" jobów. Taka niestety nasuwa się konkluzja z ost. kilku dni.

A co to dokładnie oznacza?
Ano nic innego, ze Piotrek nie umie rozmawiać z ludźmi. Przejmując x syst. informatycznych po swoich poprzednikach, nie zawsze potrafił się dopytać, czy wersje testowe (aplikacji oraz bazy danych) służą do tego, aby programiści mogli na nich cokolwiek testować i broń boże puścili na tym, jakiś update. Szczególnie taki, który działa co noc na prod. i kilka dni temu się wysypał, a ja własnie zrobiłem na niego fixa. O to to nie. Aplikację powinno się przetestować lokalnie, a później, po stwierdzeniu że "u mnie działa" wgrywać od razu na produkcję :/

Jakiś czas temu, podjąłem się zadania przejęcia całej infrastruktury programistycznej w pewnej firmie po tym, gdy odszedł z niej ost. programista i przez kilka tyg. żadne ze stanowisk programistycznych nie było obsadzone. Dużo ich nie było, tj. 2, ale w zasadzie przejmowałem 12 mniej lub bardziej rozbudowanych syst,. informatycznych (największa baza 16 GB danych), a w praktyce żyjący własnym życiem mechanizm naczyń połączonych. Oczywiście, większość aplikacji miała swoich opiekunów biznesowych. O ile miałem parę spotkań z moim poprzednikiem, jednak w praktyce najczęściej koncentrowały się one wokół spraw bieżących, lub przyszłego, nowego syst. który trzeba dopiero napisać.

O ile, z ludźmi z IT rozmawiałem i... np. Adam mnie uprzedził, ze w jego syst. aplikacje "test" oraz "test2" nie są dla mnie dostępne (i stworzył mi inne środ. testowe) o tyle ludzi "biznesowych", którzy zazwyczaj obrażają się o to, ze mówię techniczne słowa, których nie rozumieją, o takie zmiany za bardzo nie podejrzewałem. I masz tu babo placek.

Wysypał się job robiący aktualizację. Znalazłem błąd, poprawiłem go i sru na test. Na teście przeszło to na prod. Fix zrobiony, sprawa rozwiązana i super. A tu niestety nie ma tak dobrze. Opiekun biznesowy, który nie umie pisać skryptów (bo po co mu to), ani tym bardziej zrobić backupu bazy... miał tam jakieś swoje dane, który nocny import mu nadgrał.

Oj Piotrek, Piotrek, I co żeś ty uczynił?
I co ważniejsze? Co też masz teraz zrobić? Porobić własne instancje testowe wszystkich działających usług, skryptów, aplikacji, baz danych? Co noc backupować bazy testowe? A może jednak rozwiązaniem jest, aby dziennie spędzać więcej czasu  na tel. rozmawiając z opiekunami biznesowymi, niż na faktycznym kodowaniu tych systemów?

Normalnie murarz, tynkarz, akrobata...

AutoMapper

    Jednym z ćwiczeń praktycznych podczas "Zaawansowanego szkolenia z .NET 4.0" organizowanego przez Comarch (opis szkolenia tutaj), było napisanie własnego "AutoMappera" na kilka możliwych sposobów (refleksja, dynamic).
    A czym właściwie jest "AutoMapper"? AutoMapper to biblioteka, która udostępnia funkcjonalność automatycznego przepisywania wartości pól jednej klasy do drugiej. Potrzeba posiadania takiej funkcjonalności często zachodzi w sytuacji wykorzystywania w projekcie ORM. Zamiast pisać kod, służący do mapowania pól/właściwości z jednej klasy do drugiej, lepiej jest wykorzystać gotowe, darmowe rozwiązanie jakim jest AutoMapper, szczególnie, że jego wykorzystanie jest banalnie proste:

Najpierw, przed pierwszym użyciem tworzymy konfigurację mapowania (w jednym miejscu dla całego AppDomain). Najczęściej będzie to 'global.asax' lub 'bootstraper', ale może być też bezpośrednio przed metodą:

public static IMappingExpression<TSource, TDestination> CreateMap<TSource, TDestination>();
np.: Mapper.CreateMap<ClassA, ClassB>();

a nast. w kodzie produkcyjnym do mapowania wykorzystujemy metodę Map:

public static TDestination Map<TDestination>(object source);
np: ClassA classAB = Mapper.Map<ClassA>(classAA);  

//classAA will be copied to classAB and both will have values of classAA

Testowanie:
Najpierw musimy zainicjować konfigurację mapowania (np. poprzez wywołanie Bootstrapera), a nast. wywołać metodę:

Mapper.AssertConfigurationIsValid();

Linki:
Kod źródłowy znajduje się na github, a udost. jest na licencji MIT.
AutoMapper Getting-started
Artykuł na Visual Studio Magizne opisujący bardziej zaawansowane przypadki użycia: link

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);
    }

Chrome DevTools

Jak powszechnie wiadomo, każda praca wymaga specyficznych dla tej pracy narzędzi. W przypadku hydraulika jest to klucz francuski, w przypadku nauczyciela jest to tablica, a przypadku web developera są to tzn. 'DevTools'. Osobiście, do tej pory, jako 'DevTools' używałem narzędzi dostępnych w Internet Explorer (od wersji 8.0). Owszem, byłem świadomy "firebuga" występującego w 'mozilla firefox', jednak siła przyzwyczajenia była zbyt silna, aby się przemóc.'Narzędzia developerskie IE' pokazał jeden z kolegów z pierwszej pracy i... tak jakoś zostało. Do dzisiaj.

Pod wpływem kilku ost. wykładów Gutka (więcej info w moim poprzednim wpisie), postanowiłem poszerzyć moją wiedzę o to, co zaserwował nam Gutek podczas swoich wykładów.

Jednym z miłych zaskoczeń są narzędzia developerskie dostarczone nam przez firmę Google dla ich przeglądarki Chrome o nazwie "Chrome DevTools".

To co jest naprawdę fajne, to fakt, iż google, oprócz dostarczenia nam porządnych narzędzi udostępnia również mini-tutorial, w którym oprócz "wykładów" (filmiki) mamy też do wykonania część praktyczną (ponieważ jak to mówi miły pan na filmiku "nic nie zastąpi praktyki" ;)).

To co mnie najbardziej urzekło w "Chrome DevTools", to możliwość sprawdzania wydajności stron i sposób konkretnego wyszukiwania "wąskiego gardła" (tzw. "bootle neck"), z dokładnością do linii kodu, zarówno przy ładowaniu strony do przeglądarki, jak i późniejsza obsługa tego kodu w przeglądarce.

Link do samouczka z Chrome DevTools


p.s. W kursie jest również odnośnik do innej strony hostowanej przez google (closure-compiler), służącej do minimalizowania objętości plików js (w celu zwiększenia wydajności stron, które tworzymy).

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ć.