Scrutor to sprytna biblioteka, która pozwala na automatyczną rejestrację zależności (dependency injection) dla kontenera IOC Microsoft.Extensions.DependencyInjection.
Czytaj dalej...Ostatnio miałem potrzebę stworzenia konfiguracji w TeamCity, w której build jest triggerowany, gdy tworzymy nowego taga. Przydaje się to w szczególności na branchu master, gdy nie chcemy tworzyć builda lub/i kalkulować nowej wersji podczas każdego commita, a jedynie wtedy kiedy sami, w sposób explicite, stworzymy nowy tag (wersję). Niestety, aktualnie TeamCity nie wspiera jeszcze tej funkcji, ale jest na to workaround. Poniżej podaję gotowy przepis na tę konfigurację.
Czytaj dalej...W testach bardzo często mamy do czynienia z powtarzaniem tego samego kodu. Tak samo ma się sprawa z testowaniem null-checków (zw. inaczej jako guard clauses) w konstruktorach. Jeśli chcemy napisać test dla takiego przypadku, to zazwyczaj jest on napisany jako osobna metoda. Jak możemy sobie uprościć życie? Z pomocą przychodzi biblioteka AutoFixture.Idioms.
Czytaj dalej...Właśnie niedawno zakończyłem migrację bloga z Wordpressa do GitHub Pages...
Czytaj dalej...Tym razem bardzo krótko: Książka w temacie TDD jest już w sprzedaży. Gorąco zachęcam do przyjrzenia się, zakupu, recenzji i dawania feedbacku.
Czytaj dalej...Ogromnie miło mi poinformować, że zapowiadana książka o TDD jest już w przedsprzedaży! Na stronie wydawnictwa Helion można poznać więcej szczegółów odnośnie książki, t.j. cenę, spis treści i przykładowy rozdział.
Czytaj dalej...Mały update odnośnie książki „TDD. Techniki programowania sterowanego testami”, której premiera zbliża się wielkimi krokami…
Czytaj dalej...Czołem! Jakiś czas temu (pierwszy commit wskazuje na 13 marca 2016) postanowiłem przekuć posty z bloga związane z TDD na książkę właśnie w tym temacie…
Czytaj dalej...NUnit w wersji 3.6 wprowadził dość ciekawą funkcję — Assert.Multiple. Dzięki niej, dostajemy informacje na temat wszystkich testów, które nie przeszły. Przyjrzyjmy się temu bliżej… Do tej pory, używając kilku asercji naraz, jedna niespełniona asercja powodowała, że dalszy kod nie jest wykonywany.
Czytaj dalej...Test-Driven Development pojawia się w kontekstach: techniki, metody, metodologii i metodyki. Które z tych określeń poprawnie definiuje TDD?
Czytaj dalej...Jeśli estymacja czasowa nie sprawdza się w naszym projekcie (co jest wielce prawdopodobne w przypadku oprogramowania), to możemy się posłużyć estymacją relatywną.
Czytaj dalej...Estymacja, czyli szacowanie projektu programistycznego to bardzo często bolączka każdego zespołu. Czego użyć do szacowania naszego projektu: estymat godzinowych, roboczodniowych, Story Pointów, koszulkowych. A może w ogóle nie korzystać z estymat (#NoEstimates)? Postaram się przedstawić sposoby oraz zalety i wady każdej z tych metod estymacji, zaczynając od tego postu i estymat czasowych.
Czytaj dalej...Minęło łącznie 1255 dni od opublikowanego 20 kwietnia 2013… Był to pierwszy post na tym blogu, a sam kurs miał dyktować kierunek tego bloga na najbliższe 2-3 lata. Kończąc cykl częścią 25. nadszedł czas na mini-podsumowanie kursu…
Czytaj dalej...To już ostatnia część kursu TDD (przed podsumowaniem) na tym blogu. Tym razem, formuła artykułu jest odmienna. Zamiast przedstawiać dane zagadnienie, to ja pytam Ciebie, czytelniku, o TDD... Jeśli uczysz się TDD, to warto przed wygooglowaniem odpowiedzi zastanowić się nad każdym z tych punktów i postarać się odpowiedzieć na pytanie. W przypadku, kiedy twój zespół uczy się TDD, to polecam zrobić brainstorming i do każdego pytania zebrać odpowiedzi grupy. Prowadząc kilka szkoleń na ten temat, zauważyłem że taka formuła sprawdza się idealnie jeśli te pytania na zadamy na początku i jeszcze raz, na końcu kursu, porównując odpowiedzi.
Czytaj dalej...Najprawdopodobniej spotkałeś się z tym problemem: Kod zastany, napisany przez nas lub nie, na pewno nie perfekcyjny i ostatecznie bez testów jednostkowych (ang. legacy code). Co teraz? Wstrzymać dotychczasowe prace nad projektem i pisać testy jednostkowe? A może całkowicie zaniechać pisania testów, bo skoro nigdy nie było testów, to po co pisać je teraz? Do tej pory omawialiśmy TDD z perspektywy pisania nowego kodu. Jak wygląda sytuacja w przypadku istniejącego już kodu?
Czytaj dalej...Test-Driven Development ma niezaprzeczalnie bardzo pokaźną liczbę zalet, jednak jednym z problemów stojących na przeszkodzie we wdrożeniu i stosowaniu tej techniki jest fakt, że pisanie testów jednostkowych wymaga większego nakładu czasowego programisty. Nie licząc czasu na zmianę sposobu myślenia oraz naukę zespołu, pisanie testów jednostkowych może trwać nawet dwukrotnie dłużej niż w sposób
Czytaj dalej...Przyjrzymy się bliżej tematowi pokrycia kodu testami (code coverage).
Czytaj dalej...Rodzaje framerków do tworzenia atrap możemy podzielić na dwie kategorie: constrained (z ang. ograniczony) i unconstrained (nieograniczony)
Czytaj dalej...Jedną z największych trudności dla osoby zaczynającej przygodę z testami jednostkowymi są metody i klasy statyczne oraz niederministyczne lub/i niepowtarzalne zależności. Testy jednostkowe muszą być deterministyczne i powtarzalne. Musimy przyjąć zatem strategię wstrzykiwania alternatywnej implementacji dla wywołań DateTime.Now, funkcji losującej, itp. W tym artykule przedstawię jedną ze strategii tworzenia atrap dla tego typu zależności.
Czytaj dalej...Nomenklatura w świecie TDD, a w szczególności ta dotycząca tworzenia atrap, jest źródłem wielu niejasności. Powodem takiego stanu jest fakt, że definicje różnią się w zależności od źródła, tj. książki, lub frameworka. W tym wpisie poznamy charakterystykę takich obiektów testowych jak mock, stub, fake, spy i dummy.
Czytaj dalej...Pora przyjrzeć się trzeciemu najpopularniejszemu darmowemu frameworkowi do tworzenia atrap w .NET – NSubstitute.
Czytaj dalej...Dziś w kursie TDD przyjrzymy się frameworkowi do tworzenia atrap, konkurencyjnemu do wcześniej poznanego Moq. FakeItEasy, bo o nim mowa, jest darmowy, łatwy w nauce, ma wsparcie dla C# i VB.NET, różni się od innych bibliotek nie tylko semantyką, ale także nieco innym podejściem do tematu tworzenia atrap.
Czytaj dalej...W tym artykule przyjrzymy się ciut bardziej zaawansowanym technikom tworzenia atrap przy pomocy Moq: argument matching, verify, callback.
Czytaj dalej...Moq to najpopularniejszy framework do tworzenia atrap w .NET. W tej części kursu poznamy jego składnię i podstawowe możliwości.
Czytaj dalej...W części czternastej kursu Test-Driven Development omówimy technikę testowania zależności za pomocą atrap (ang. mock).
Czytaj dalej...Wzorzec projektowy fluent interface (polski odpowiednik... płynny interfejs?) przyjął się w środowisku .NET-owym bardzo dobrze. I słusznie! "Płynna syntaktyka" znacznie poprawia czytelność pisanego kodu. Jednym z sztandarowych przykładów jej użycia są asercje w testach, np. przy wsparciu biblioteki Fluent Assertions
Czytaj dalej...IntelliTest to wewnętrzna funkcjonalność Visual Studio, która służy do generowania tabeli danych wejściowych oraz zestawu testów jednostkowych. Dla danej metody generowane są dane wejściowe, w oparciu których mogą zostać wygenerowane testy jednostkowe. Przypadki testowe tworzone są w oparciu o analizę każdego skoku warunkowego (conditional branch).
Czytaj dalej...Postanowiłem kiedyś stworzyć, na własne potrzeby, spis narzędzi dla TDD dla .NET. Z czasem, lista rozrosła się do narzędzi nie tylko związanych z TDD, ale także z testami akceptacyjnymi i BDD. Dokończyłem ten spis o pozostałe rodzaje testów i opublikowałem na GitHubie, tak żeby można było łatwiej aktualizować.
Czytaj dalej...C# 5.0 wniósł wiele dobroci, m.in. obsługę wywołań asynchronicznych za pomocą słów kluczowych async i await. Rozwiązanie, ze względu na prostotę obsługi i skuteczność, cieszy się do dziś sporą popularnością. Jak testować wywołania asynchroniczne? Tego dowiemy się w tym odcinku!
Czytaj dalej...Rzecz być może dla niektórych mało istotna, dla niektórych w ogóle nie istotna, ale niezależnie od istotności sprawy – myślę, że warta wpisu na blogu. NUnit posiada dwa modele asercji: Classic Assert Model oraz Constraint-Based Assert Model.
Czytaj dalej...W niniejszym artykule przyjrzymy się w jaki sposób możemy przetestować klasy generyczne za pomocą funkcjonalności NUnita pod nazwą Generic Test Fixture.
Czytaj dalej...Teoria jest specjalnym rodzajem testu, w którym weryfikujemy dane twierdzenie przy pomocy założeń (assumptions).
Czytaj dalej...Naturalnym krokiem po omówieniu testów parametryzowanych jest przejście do testów kombinatorycznych i sekwencyjnych. Do dyspozycji mamy dwa atrybuty NUnita — [Combinatorial] oraz [Sequential].
Czytaj dalej...W C# istnieje mało znana składnia do inicjalizacji zagnieżdzonych obiektów (nested object initializer syntax).
Czytaj dalej...Celem testów parametryzowanych jest przekazanie zestawu wartości danych do metody testowej. Każdy zestaw danych jest traktowany jako osobny test.
Czytaj dalej...W tej części kursu zajmiemy się pojęciem inicjalizacji i czyszczenia danych.
Czytaj dalej...W tej części opisane zostaną dobre i złe praktyki stosowane przy pisaniu testów jednostkowych.
Czytaj dalej...W tej części omówię jak wykonać kilka prostych technik, tj. jak zgrupować testy za pomocą atrybutu [TestCase], testować wyjątki, testować zdarzenia.
Czytaj dalej...W tej części cyklu stworzymy nasz pierwszy test jednostkowy. Przedstawię krok po kroku jak napisać i przetestować prostą funkcjonalność wedle zasad TDD.
Czytaj dalej...Czas na omówienie jak, strukturalnie, powinien wyglądać wzorcowy test jednostkowy (Arrange-Act-Assert).
Czytaj dalej...Garść cytatów w kontekście Test Driven Development. Można je wykorzystać przy różnych okazjach, np. przy tworzeniu prezentacji albo przy rodzinnych bankietach ;)
Czytaj dalej...W części drugiej kursu przyjrzymy się rodzajom testów w świecie Test-Driven Development i poznamy różnice między testami jednostkowymi, a integracyjnymi.
Czytaj dalej...Swój pierwszy wpis na blogu zacznę od części numeros unos cyklu poświęconemu Test-Driven Development. TDD w ostatnim czasie święci triumfy i to nie bez powodu. Dlaczego tak jest i czy gra jest warta świeczki?
Czytaj dalej...