C# Pro Tip: Nested object initializer syntax

W C# istnieje mało znana składnia do inicjalizacji zagnieżdzonych obiektów (nested object initializer syntax). Po raz pierwszy zetknąłem się z nią przy okazji lektury The C# Programming Language (Covering C# 4.0), a później przy sugestii ReSharpera.

Na czym polega cała zabawa?

Spójrzmy na kod, za pomocą którego inicjalizujemy zagnieżdżony obiekt:

Rectangle rectangle = new Rectangle
{
    P1 = { X = 0, Y = 1 },
    P2 = { X = 2, Y = 3 }
};

Czytaj dalej

Kurs TDD cz. 8: Testy parametryzowane

Temat testów parametryzowanych pojawił się przy okazji pisania naszego „drugiego” testu jednostkowego. Wtedy to skorzystaliśmy z atrybutu [TestCase] pozwalającym na zdefiniowanie zestawów wartości, które są przekazywane do metody testowej. Stosując atrybuty do testów parametryzowanych (m. in. TestCase, Values, Range, Random) ograniczamy liczbę naszych metod testowych i redukujemy ilość redundantnego kodu. Ponadto, zyskujemy na czytelności naszych testów.

Kod źródłowy do kursu TDD pojawił się na GitHubie i jest dostępny pod adresem: https://github.com/dariusz-wozniak/TddCourse. Zapraszam do ściągania i dalszej lektury…
Czytaj dalej

Kurs TDD cz. 7: Inicjalizacja i czyszczenie danych (SetUp i TearDown)

W tej części kursu zajmiemy się pojęciem inicjalizacji i czyszczenia danych. Wielkiej filozofii tutaj nie ma; w NUnit działa to tak:

  • Jeśli chcemy, aby jedna z metod uruchamiała się przed każdym uruchomieniem naszego testu, aby np. inicjalizować dane, nakładamy na nią atrybut [SetUp].
  • Jeśli zechcemy, aby metoda uruchamiała się po każdym uruchomieniu testu w celu np. czyszczenia danych — nakładamy atrybut [TearDown].

Reguły gry są jasne:

  • Jeśli użyjemy więcej niż jeden atrybut [SetUp] i [TearDown] dla jednego [TestFixture], to kod skompiluje się poprawnie, ale testy nie uruchomią się.
  • Jeśli chcemy natomiast uruchomić kod jednorazowo przed wywołaniem\po wywołaniu wszystkich naszych testów w obrębie [TestFixture], możemy skorzystać z atrybutów [TestFixtureSetUp] i [TestFixtureTearDown].

Czytaj dalej

Kurs TDD cz. 6: Dobre i złe praktyki testów jednostkowych

W tej części opisane zostaną dobre i złe praktyki stosowane przy pisaniu testów jednostkowych. Co ciekawe, praktyki te odbiegają niekiedy od ogólnie przyjętych założeń i standardów kodowania. Przykładem może być zasada DRY—Don’t Repeat Yourself. W TDD kopiuj-wklej to niemal chleb powszedni; w TDD możemy stosować zasadę zgoła odwrotną—Do Repeat Yourself! Taka odrębność wynika z tego, że w kodzie testowym musimy zminimalizować prawdopodobieństwo pojawienia się błędu. Kod testowy musi być też bardzo prosty i czytelny. Kod testowy nie jest kodem produkcyjnym i w konsekwencji nie będziemy mieli potrzeby rozwijania kodu ani jego funkcjonalności.

Czytaj dalej

Kurs TDD cz. 4: Nasz pierwszy test jednostkowy

W tej części cyklu stworzymy nasz pierwszy test jednostkowy. Przedstawię krok po kroku jak napisać i przetestować prostą funkcjonalność wedle zasad TDD. Opiszę tutaj szczegółowo wszystkie kroki, począwszy od tego jak dodać referencję do NUnita, a skończywszy na tym jak uruchomić test.

Zachęcam też do odwiedzenia ostatniej części, która opisuje strukturę kodu jednostkowego Arrange-Act-Assert. Zachęcam tym bardziej, że rozszerzyłem tę część o garść istotnych informacji. Czytaj dalej

Kurs TDD cz. 3: Struktura testu, czyli Arrange-Act-Assert

Po wstępie i omówieniu różnic między testami jednostkowymi, a integracyjnymi, czas na omówienie jak strukturalnie powinien wyglądać wzorcowy test jednostkowy. Będzie to pewnie najkrótszy wpis tej serii, ale jednocześnie jeden z najważniejszych. Pozwoli bowiem na pierwszy kontakt z testem jednostkowym w praktyce.

Czytaj dalej

Cytaty o TDD

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

Writing tests is another way to look the code and locally understand it and reuse it, and that is the same goal of good Object Oriented design. This is the reason of the deep synergy between testability and good design.
— Michael Feathers

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.
— Michael Feathers

Czytaj dalej