Snippet VisualStudio

Snippet

Przy pracy z kodem często piszemy te same bloki kodu, linijki, które zawsze wyglądają tak samo. Czy to kolejny using, czy może konstruktor, albo właściwość. Pisanie powtarzających się elementów kodu można z automatyzować wykorzystując snippety, czyli wstawki kodu, których użycie sprowadza się do wpisania skrótu i potwierdzenia dwa razy Tab-em. Visual Studio wspomaga nas jako programistów pewnym zestawem takich fragmentów kodu. Czytaj dalej Snippet VisualStudio

Refleksja – manipulacja obiektami

Refleksja, manipulacja obiektami

W poprzedniej części odczytywaliśmy metadane przy pomocy refleksji. Dzisiaj wykorzystamy te dane, ażeby manipulować obiektami, tworzyć instancje oraz zmieniać ich właściwości, czy też wywoływać ich metody. To właśnie dzięki tym mechanizmom możliwa jest implementacja  kontenerów dependency injection  (wykorzystanie możliwości kreacji obiektów), czy też runnery testów (odczyt atrybutów metod oraz ich wywołanie). Czytaj dalej Refleksja – manipulacja obiektami

Refleksja – odczyt metadanych

Refleksja

Refleksja jest mechanizmem umożliwiającym odczytywanie metadanych. Dzięki niemu możemy odczytać atrybuty i własności obiektów w bibliotekach. Dzięki temu mechanizmowi możemy bez trudu odczytywać własne atrybuty tworzone jak w poprzednim wpisie https://mateuszstanek.pl/2018/02/04/wlasny-atrybut/ Czytaj dalej Refleksja – odczyt metadanych

Własny Atrybut

Własny Atrybut

Z poprzedniego wpisu https://mateuszstanek.pl/2018/02/03/atrybut-c/  wiemy czym są atrybuty. Pora więc napisać jakiś własny. Aby to zrobić wystarczy dodać nową klasę dziedziczącą z klasy System.Attrybute oraz poinformować z jakimi elementami będzie nasz atrybut współpracował.
W tym celu wykorzystamy 3 z predefiniowanych atrybutów AttributeUsage. Czytaj dalej Własny Atrybut

Atrybuty w C#

Atrybut

Zacznijmy od tego czym jest Atrybut. A jest on niczym więcej jak dodatkowymi metadanymi, które można dodać w naszym kodzie. Atrybuty można dodawać do większości elementów klasy czy też biblioteki.
A więc do :

  • assembly
  • modułów
  • klass
  • struktur
  • enum-ów
  • konstruktora
  • metod
  • właściwości
  • pól
  • eventów
  • Interface
  • parametrów
  • delegatów
  • wartości zwracanych
  • parametrów generycznych

Atrybuty w C# zapisuje się w nawiasach Kwadratowych „[MójAttrybut]” nad lub przy odpowiednim elemencie, do którego ma zostać dodany dany atrybut. Czytaj dalej Atrybuty w C#

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.

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:

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)

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.