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