Książka o TDD – już w przedsprzedaży!

Hej! 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ł.

Podstawowe pytanie, jakie się nasuwa to… Czy warto zainwestować w książkę skoro jest już kurs TDD online na tej stronie? Przede wszystkim, to temat testowania jednostkowego został w książce znacznie rozszerzony. Kilkuletnia analiza tematu pozwoliła na całkiem sporo nowych informacji, przemyśleń, wniosków, ale także i pytań. Książka została starannie sprawdzona pod względem merytorycznym, jak i językowym przez kilku profesjonalistów. Dzięki edycji zdałem sobie też sprawę, jak dużo błędów popełniam w jednym tylko zdaniu… No i spora część wiedzy z bloga została zaktualizowana i rozszerzona.

Książka wydana będzie w formie papierowej i e-booka. Którą wersję mógłbym zarekomendować? Tutaj będę tradycjonalny i polecę wersję papierową. Książkę pisałem z zamysłem, aby stanowiła nie tylko spory tutorial, ale też swego rodzaju manual, do którego sięgniemy gdy zapomnimy o jakiejś technice, np. “w jaki sposób robiło się testy parametryzowane z użyciem danych z innej klasy?” Moja osobista preferencja do tego typu książek to druk, wybór pozostawiam już w Twojej gestii ;-)

Jeśli już nie możesz doczekać się książki, to warto sięgnąć po repozytorium na GitHubie i przeczytać kod (tak – czytanie kodu to również zajęcie dobrego programisty), który został tam zamieszczony.

Przed zakupem warto przyjrzeć się też przykładowemu rozdziałowi, aby zaznajomić się z formułą i stylem książki. Daj mi znać czy już na tym etapie podoba Ci się lub nie. Jeśli znajdziesz gdzieś błąd lub z czymś nie zgadzasz, zapraszam do kontaktu i polemiki :-)

Pssst… już niedługo, książka o TDD!

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. Początkowo zakładałem edycję obecnych postów, poprawki, aktualizację i wydanie w formie książki online. W tym czasie odezwał się do mnie Helion z zapytaniem czy byłbym zainteresowany kursem video TDD. Zamiast video, zaproponowałem wydanie książki. Dla mnie to była doskonała opcja, ponieważ tego typu publikacja byłaby związana z wysokim jej poziomem. Po niespełna dwóch latach udało mi się tę książkę napisać, a obecnie trwa korekta merytoryczna i edytorska. Książka podąża innym torem nauki niż zamieszczony na stronie kurs TDD. Przede wszystkim, każda z poruszonych kwestii została mocno rozwinięta i znacząco poprawiona. Wzbogaciłem temat o własne doświadczenia, głównie w prowadzeniu szkoleń w tym temacie i pracy nad kodem w różnych projektach.

2018-01-20 18_41_02-TDD. Techniki programowania sterowanego testami Książka, kurs - Dariusz Woźniak

Książka ma tytuł “TDD. Techniki programowania sterowanego testami“, a jej premiera przewidziana jest na kwiecień 2018. Szczegóły zawartości można obejrzeć na stronie Helionu w dziale Zapowiedzi: https://helion.pl/ksiazki/tdd-techniki-programowania-sterowanego-testami-dariusz-wozniak,tddppr.htm. Gorąco zachęcam do śledzenia premiery i lektury, gdy będzie dostępna!

Assert.Multiple

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.

Continue reading

TDD: Technika, metoda, metodologia czy metodyka?

Test-Driven Development pojawia się w kontekstach:

  • techniki,
  • metody,
  • metodologii
  • i metodyki.

Które z tych określeń poprawnie definiuje TDD?

Zacznijmy od definicji poszczególnych pojęć:

technika:

«wiedza na temat praktycznego wykorzystania osiągnięć nauki w przemyśle, transporcie, medycynie itp.; też: praktyczne wykorzystanie tej wiedzy»

lub:

 «metoda»

metoda:

«świadomie stosowany sposób postępowania mający prowadzić do osiągnięcia zamierzonego celu»

metodologia:

«nauka o metodach badań naukowych stosowanych w danej dziedzinie wiedzy»

metodyka:

«zbiór zasad dotyczących sposobów wykonywania jakiejś pracy»

Werdykt: TDD to technika, metoda lub metodyka tworzenia oprogramowania. Nazywanie TDD metodologią jest błędne.

Źródło: http://sjp.pwn.pl

Kurs TDD – update źródeł

FYI—

Zaktualizowałem biblioteki dla projektu TDD Course https://github.com/dariusz-wozniak/TddCourse:

  • NUnit 2.6.4→3.5.0
  • Moq 4.2.1510.2205→4.5.23.0
  • FluentAssertions 4.1.1→4.15.0

Co za tym idzie:

  • W najnowszym NUnicie nie jest wspierany atrybut ExpectedException. Był opisany w części o testowaniu wyjątków. Zamiast atrybutu, powinno się używać Assert.Throws lub podobnych.
  • Zmieniła się idea testowania wywołań asynchronicznych, co opisywała część 13. kursu.

Wszystkie zmiany znajdują się w commicie:

https://github.com/dariusz-wozniak/TddCourse/commit/180846157f6b7506b268c14a5a51cad2059bbb0e

Podsumowanie kursu TDD

Minęło łącznie 1255 dni od pierwszej części kursu TDD 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…

Dlaczego napisałem ten kurs?

Problem jaki powstał przy mojej nauce TDD to przede wszystkim brak źródła informacji, który oprowadził by mnie od początku do końca po tematyce testów jednostkowych dla .NET. Owszem, było w tym czasie sporo źródeł, jednak wiedza oparta w tych źródłach była albo dostosowana pod inny język, albo nieaktualna (Rhino Mocks, MsTest), albo najzwyczajniej w świecie rozrzucona po blogach i StackOverflow. Było jest i sporo świetnych artykułów, które traktują TDD dla .NET, także w polskiej blogosferze, ale brakowało jednak poprowadzenia programisty, przysłowiowo, za rękę.

Pomyślałem, że taki kurs to świetne paliwo do bloga, zebrałem i zapisałem różne wycinki i magic – zacząłem pisać :) Moim zamiarem było stworzenie cyklu, który poprowadzi programistę przez ścieżkę nauki TDD – począwszy od napisania pierwszego testu jednostkowego, po mockowanie, aż po rozważania teoretyczne.

Sama tematyka to nic nowego w świecie programistycznym. I, jakby się mogło wydawać, nic też trudnego. W praktyce może to wyglądać jednak zupełnie inaczej. Istotną kwestią jest, prócz przygotowania merytorycznego, kultura zespołu i firmy. Jeżeli zatem brakuje czasu na setup i zrobienie porządków z unit testami, należałoby się zastanowić nad kulturą miejsca pracy. Z tego też powodu wysnułem kilka rozważań na temat kilku pułapek (code coverage), jak i podstawowego pytania – czy to się w ogóle opłaca?

Continue reading

Kurs TDD cz. 25: Otwarte pytania

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.

Continue reading

Kurs TDD cz. 24: Czy pisać testy jednostkowe do istniejącego kodu (legacy code)?

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? Na początek warto zastanowić się nad kilkoma pytaniami:

  • Czy powinno się poświęcać czas i zasoby, czasem wstrzymując dotychczasowe prace, na pisanie testów jednostkowych do kodu już istniejącego?
  • …Jeśli tak, to którą część aplikacji pokryć w pierwszej kolejności?
  • Jak bezpiecznie refaktoryzować kod, aby nie wprowadzić błędu do istniejącego kodu?
  • W jaki sposób powinno się pisać kody jednostkowe przy wprowadzaniu zmian do istniejącego kodu?

Continue reading