Mateusz Stanek - Technika i technologia

Testy – błędne wyniki

Testy

O tym jak ważne są testy chyba nie muszę nikomu mówić, nie mniej jednak są sytuacje, kiedy testy dają nam fałszywe poczucie bezpieczeństwa. W jednym z projektów jakie miałem okazje realizować, klient podchodził do testów bardzo rygorystycznie. Podeście to, w pewnym momencie przekroczyło moim zdaniem granicę absurdu, kiedy to została zatrudniona osoba, specjalnie po to, ażeby pisała test. Testy post-factum do kodu, którego nie znała, rozwiązującego problemy, których nie rozumiała. Wartość tych testów była jak by to powiedzieć niezbyt wysoka. Klient był zadowolony, pokrycie kodu testami rosło. Zespól tworzył testy jakie uważał za konieczne, a dedykowany developer uzupełniał testy do magicznego wymaganego przez klienta poziomu pokrycia.

Błędne wyniki

O jakości testów przekonaliśmy się w momencie, w którym konieczne były zmiany. Jak wiadomo testy przy zmianach są ważne, gdyż pozwalają sprawdzić czy główne funkcje klas pozostają niezmienione. Tutaj zetknęliśmy się z jednym z błędnych wyników.

Testy – False Positive

Fałszywie pozytywne testy, są szczególnie niebezpieczne według mnie, gdyż dają złudne poczucie bezpieczeństwa. Bezpieczeństwa, które przy zmianach jest jakże ważne. Zmieniamy coś, uruchamiamy testy, sprawdzamy podstawową ścieżkę wykonania – działa, działa. Niestety zmiany nie były takie niewinne. Z powodów braku wiedzy o warunkach brzegowych testy pokrywały całą klasę, ale specyficzne przypadki nie były testowane, o czym ów piszący testy developer nie wiedział (tak, tak daliśmy ciała nie pisząc tych testów wcześniej). Problem na szczęście wyszedł w czasie testów manualnych. Cała ta sytuacja zapaliła u nas światełko ostrzegawcze i zmusiła cały zespól do refleksji, na temat jakości testów oraz baczniejszego zwracania na nie uwagi.

Testy – False Negative

Ten przypadek testów jest mniej niebezpieczny od opisanego wcześniej „False Positive”, jest on jednak dużo bardziej denerwujący. Odnosi się do przypadku, w którym, mimo iż implementacja jest prawidłowa testy failują. Odruchowo sprawdzamy co może być nie tak i szukamy w pierwszej kolejności problemów w zmienionym kodzie, a dopiero później w implementacji testów. Warto dodać, iż tego typu problemy występują szczególnie często po znalezieniu błędów w implementacji, gdzie pierwszą rzeczą powinno być poprawienie (bądź dodanie nowych) testów, na takie, ażeby błąd został odkryty w testach, a następnie poprawiona implementacja. Może to dać nam fałszywie negatywne wyniki testów w przypadkach, o których nie pomyśleliśmy w czasie poprawek. Nie ważne jak znaleźliśmy takie testy, poprawka w takich przypadkach powinna zostać starannie przemyślana i wykonana z rozwagą tak, ażebyśmy nie stali się ofiarami testów fałszywie pozytywnych.

Podsumowanie

Nie jestem specjalistą od testów. Jednakże w czasie pracy spotkałem się z różnymi przypadkami, gdzie testy ratowały nam skórę, jak i takie, gdzie zepsuły nam naprawdę wiele krwi. Zwracajmy uwagę na nasze testy i w miarę możliwości starajmy się być świadomymi wszelkich zagrożeń. A co najważniejsze, jeśli mamy wiedzę o warunkach specjalnych, które mogą być ciężkie do wyłapania piszmy testy, w których będą one specjalnie, może nawet nadmiarowo testowane. Pozwoli nam to uniknąć późniejszych problemów.

Enumeracja – wartość domyślna

Pracując w świecie .NET-a często korzystam z typu wyliczeniowego. Enumeracje stosujemy wszędzie tam, gdzie chcemy zwracać wartości, gdzie każda z nich ma jakieś znaczenie. Czytaj dalej Enumeracja – wartość domyślna

ASP.NET Core MVC – Konfiguracja

Było trochę o konfiguracji hosta, było o konfiguracji aplikacji, więc na spokojnie możemy przejść do konfiguracji i uruchomienia aplikacji MVC. W tym celu dodamy prosty kontroler oraz widok do naszej aplikacji oraz skonfigurujemy router. Ale zacznijmy od początku. Czytaj dalej ASP.NET Core MVC – Konfiguracja

Komentarz (nie)zbędny ?

TL;DR;

Dodawajmy komentarze rozważnie i tylko wtedy, kiedy ich zastosowanie ma sens. Przed dodaniem komentarza przemyśl czy jest on potrzebny czy jest tylko wymówką do nie zmieniania kiepskiego kodu. Czytaj dalej Komentarz (nie)zbędny ?

Podstawy ASP.NET Core – część 2

Podstawy ASP.NET Core

Zgodnie z obietnicą dzisiaj przejdziemy przez 2 klasę konfiguracyjną, która tym razem konfiguruje już zachowania samej aplikacji webowej.

Startup.cs

W klasie tej mam 1 wymaganą metodę oraz 1 opcjonalną. Obie te metody odpowiadają za konfigurację zachowań aplikacji webowej.

Configure

Jest jedyną z wymaganych metod, która służy do konfigurowania pipelinów dla requestów. Przykładowa metoda może wyglądać tak:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole();

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            
            app.Run(async (context) =>
            {
                await context.Response.WriteAsync("Hello World!");
            });
        }

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)

{

loggerFactory.AddConsole();

if (env.IsDevelopment())

{

app.UseDeveloperExceptionPage();

}

app.Run(async (context) =>

{

await context.Response.WriteAsync("Hello World!");

});

}

Jak widzimy dodane tutaj jest provider dla logowania do konsoli (linia 3).
Więcej o providerze logowania możemy poczytać tutaj. Niemniej jednak w najbliższej przyszłości postaram się również o tym napisać nieco więcej. Prawdopodobnie spróbuję dodać do logowania własną klasę lub też wpiąć w proces jakiś dostępny w .NET Core logger.

Kolejnym elementem jest sprawdzenie zmiennej określającej środowisko, w tym przypadku sprawdzamy czy działamy na środowisku developerskim, jeśli tak wykorzystujemy odpowiednią stronę do obsługi błędów. Tutaj przydałaby się sekcja else, która wykona przekierowanie do customowej strony błędu na środowisku produkcyjnym ale w tej chwili nie będę się tym zajmował z racji na to, iż nie mam jeszcze żadnej strony w moim projekcie.

Ostatnim elementem w tej bardzo ale to bardzo prostej aplikacji jest wywołanie metody Run na appBuilderze (linia 10), gdzie w postaci delagata podawana jest metoda jaka ma się wykonać po przyjściu requesta. W tym miejscu warto dodać, iż wywołanie metody Run kończy pipeline. Aby stworzyć łańcuch wywoływanych klas middleweru należy wykorzystać metodę Use. Więcej o tym na pewno jeszcze napiszę w najbliższym czasie. Niemniej jednak więcej można poczytać tutaj.

ConfigureServices

Metoda ta jest opcjonalna, aczkolwiek jeśli zostanie wykorzystana będzie ona wywołana przed metodą Configure. Metoda ta służy do dodawania serwisów do naszej aplikacji. Tak naprawdę jest to prosty kontener dependecy injection, gdzie implementację interfejsów Microsoft nazwał serwisami. Na uwagę zasługuje fakt, iż ten kontener jest gotowy do pracy niejako z „półki” nie musimy ściągać żadnych nowych komponentów. Możemy go użyć lub też zastąpić kontenerem, który lubimy.

W ten sposób przebrnęliśmy przez podstawowe klasy konfigurujące, zarówno aplikację konsolową, która hostowała naszą aplikację web-ową oraz nią samą.

Konfiguracja Hosta

W tym miejscu chciałbym jeszcze na moment wrócić do pliku Program.cs. i jednej z wielu niewykorzystanych przeze mnie rozszerzeń interfejsu IWebHostBuildera, a mianowicie o metodzie UseUrls (linia 4)

var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseUrls("http://localhost:5000")
                .UseStartup<Startup>()
                .Build();

var host = new WebHostBuilder()

.UseKestrel()

.UseContentRoot(Directory.GetCurrentDirectory())

.UseUrls("http://localhost:5000")

.UseStartup<Startup>()

.Build();

Metoda ta służy do określania, na którym porcie ma nasłuchiwać Kastrel. Należy tutaj zwrócić szczególna uwagę na to, iż w tym przypadku nie mamy integracji z IIS-em. Jeżeli jednak wykorzystalibyśmy metodę UseUrls a następnie integrację z IIS-em to nasze ustawienia zostałyby nadpisane przez integrację. Natomiast wywołanie UseUrls po integracji z IIS-em może skutkować trudnym do zlokalizowanie błędem, gdyż ustawienia portu zostaną nadpisane naszymi wartościami.

Podstawy ASP.NET Core – część 1

Podstawy aplikacji ASP.NET Core – Main

Klasa Program.cs w aplikacji webowej w ASP.NET Core wygląda mniej więcej tak:

public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }

public static void Main(string[] args)

{

var host = new WebHostBuilder()

.UseKestrel()

.UseContentRoot(Directory.GetCurrentDirectory())

.UseIISIntegration()

.UseStartup<Startup>()

.Build();

host.Run();

}

jak widzimy przy wykorzystaniu WebHostBuilder-a tworzymy aplikację, która to hostuje naszą aplikację web-ową. W .NET Core nie mam innego wyjścia. Czytaj dalej Podstawy ASP.NET Core – część 1

ASP.NET Core MVC

MVC – Model View Controller

MVC jest wzorcem architektonicznym, umożliwiającym łatwe oddzielenie widoku (View), od modelu biznesowego (Model) oraz struktury sterującej (Controller). Wzorzec ten jest bardzo mocno eksploatowany w aplikacjach webowych. Takie wykorzystanie MVC w aplikacjach webowych spowodowało, iż wiele narzędzi i frameworków webowych ma mocne wsparcie dla samego MVC. W przypadku ASP.NET Core mamy bibliotekę ASP.NET Core MVC, które ułatwia działanie z tym wzorcem, co więcej możemy bezpośrednio przy tworzeniu projektu wybrać template MVC. Czytaj dalej ASP.NET Core MVC

.NET Core – początek

.NET Core

Czym tak właściwie jest .NET Core ? Jako programista aplikacji głównie desktopowych zazwyczaj pracuję z pełnym .NET frameworkiem. Jak wiadomo aplikacje takie można uruchomić tylko na komputerach, które taki framework posiadają zainstalowany w systemie. Tutaj cały szkopuł .NET framework jest windowsowy, co ogranicza nas tylko do komputerów z windowsem. Co prawda są próby przeportowania .NET-a na systemy linuxowe ale nie wszystko tam musi działać, a i są one zazwyczaj w niższych wersjach .NET-a niż najnowszy. Tutaj wchodzi .NET Core, który z założenia miał być wieloplatformowy, dzięki czemu aplikację napisaną z wykorzystanie tej wersji frameworka można uruchomić zarówno na Windowsie jak i Linuxie czy MacOS-ie. Pozwala to w większym stopniu dotrzeć z aplikacjami do użytkowników pozostałych platform.

Czytaj dalej .NET Core – początek

Daj Się Poznać 2017

Daj się poznać 2017

Kolejna edycja konkursu programistycznego Daj się poznać już niebawem. Osobiście chcę wziąć udział w tym konkursie, a materiały publikowane będą właśnie pod tym tagiem.

Konkurs polega na prowadzeniu projektu programistycznego przez 10 tygodni, gdzie postępy będą raportowane przynajmniej 1 postem tygodniowo oraz dodatkowo postem technicznym, nie koniecznie związanym z projektem. Czytaj dalej Daj Się Poznać 2017

Nowa droga czy stara ?

Wczoraj miałem ciężki temat do rozgryzienia i chciałbym się podzielić moimi przemyśleniami. Co się stało? Ano po długich próbach zmiany bieżącego projektu, udało mi się. Ale jak wiadomo od przybytku głowa nie boli, a może? Długo czekałem na jakąś zmianę, a tu nagle 2 opcje – rozwijanie projektu opartego o Pythona, którego znam tylko pobieżnie lub rozwijanie aplikacji desktopowej w C#, WPF-ie i MVVM-ie. Programowaniem zawodowo zajmuje się już 5 lat, gdzie przeszedłem już przez kilka projektów głównie .NET-owych. I stanąłem przed dosyć niespodziewanym wyborem. Czytaj dalej Nowa droga czy stara ?