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.

Every experienced developer knows how important is to cover your code with tests (or at least business logic). However, not everyone likes to do that once code is already written, because, why should we do that? The work is done, it was tested and it functions correctly, right? I never liked to cover the code with tests once it’s already there. That’s why in this article I’ll present TDD and describe how I use it day to day.

Na przykładzie programu rozpoznającego waluty. Postarałem się pokazać jak łatwiejsza jest refaktoryzacja kodu przy użyciu TDD.

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.

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

Niedawno zacząłem praktyki, gdzie biorę udział w eksperymencie porównania 3 metodyk pisania oprogramowania: TDD, ITL i NUT. TDD spodobało mi się szczególnie, więc postanowiłem napisać tego posta i pokazać przykładowy workflow w TDD.

Zarówno o BDD, jak i TDD wiele razy już pisałem. Najważniejszą rzeczą w TDD jest sekwencja red-green-refactor.  Zwykle BDD\TDD przybiera następującą postać: Zaczynamy od etapu BDD. Definiujemy wymagania za pomocą języka rozumianego zarówno przez programistów jak i jak BA\PO. Za pomocą Specflow możemy zdefiniować np. następujący test: Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then 120 sho...

In 2014, Internets went loud after Erik Meijer’s talk One Hacker Way. I really liked this talk, because it made me think…actually even until today I didn’t figure out everything Erik meant. Unfortunately, most of people didn’t understand this talk. In 2015, he gave the same talk again, but the rhetoric was way different. It’s more straight forward, and probably more people understood it. tl;dr This talk is about approach to software engineering...

Jedną z największych trudności dla osoby zaczynającej przygodę z testami jednostkowymi są: Metody i klasy static. Niederministyczne lub/i niepowtarzalne zależności.

Pora przyjrzeć się trzeciemu najpopularniejszemu darmowemu frameworkowi, obok Moq i FakeItEasy, do tworzenia atrap w .NET – NSubstitute. Co wyróżnia tę bibliotekę:Główny nacisk położono na prostotę w semantyce. Składnia biblioteki ma w założeniu jak najbardziej przypominać naturalny język. Ilość wyrażeń lambda została zredukowana do minimum.