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!

SpecFlow: #error Generation error: Could not load file or assembly ‘Microsoft.Build.Framework, Version=15.1.0.0…

Od pewnego czasu SpecFlow zaczął generować pliki testowe z zawartością:


#error Generation error: Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Gdybyście dostali ten sam błąd (zakładam, że wszyscy którzy go mają, przyszli z Google/DuckDuckGo) i nie mogli go zwalczyć, to tu jest recepta na naprawę. Dopóki nie ma poprawki błędu w SpecFlow (2.2.1), to można błąd obejść w następujący sposób:

  1. Wyłącz autogenerowanie testów: Prawym na pliku(-ach) *.feature Properties > Custom Tool powinno być puste.

  2. Ustaw opcję generowania plików na etapie budowania. W pliku projektowym .csproj dodaj na końcu:

<Import Project="..\packages\SpecFlow.2.2.0\tools\TechTalk.SpecFlow.targets" Condition="Exists('..\packages\SpecFlow.2.2.0\tools\TechTalk.SpecFlow.targets')" />
  1. Ustaw opcję dodawania do projektu wygenerowanych plików automatycznie. W pliku projektowym .csproj dodaj na końcu:
<Target Name="AfterUpdateFeatureFilesInProject">
    <!-- include any files that specflow generated into the compilation of the project -->
    <ItemGroup>
        <Compile Include="@(SpecFlowGeneratedFiles)" />
    </ItemGroup>
</Target>

I tyle, powinno hulać! :)

Wiecej na temat generowania plików przez MsBuild: http://specflow.org/documentation/Generate-Tests-from-MsBuild/

Issue na GitHubie: https://github.com/techtalk/SpecFlow/issues/857

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

Estymacja: Czym są Story Pointy?

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ą. Wielkość relatywna ma, w przeciwieństwie do estymaty bezwzględnej (najczęściej czasowej), ogromną przewagę, gdyż:

  • Minimalizuje błędy związane z przewidywaniem czasu poświęconego na złożone i skomplikowane zadania.
  • Ludzie, co dowiodły liczne badania naukowe (oraz być może praktyka czytelników), są słabi w szacowaniu.
  • Ludzie też, co również dowiodły badania naukowe, są lepsi w ustalaniu relatywnych, nie bezwzględnych, estymacji.
  • Nie wiąże estymaty ze zobowiązaniem zespołowym (ang. commitment).

Continue reading

Estymacja czasowa/godzinowa (oraz Cynefin Framework, PERT)

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

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 #yolo?

Postaram się przedstawić sposoby oraz zalety i wady każdej z tych metod estymacji, zaczynając od tego postu i estymat czasowych.

Ludzka natura i błędy poznawcze

 planning-fail-500x372 Źródło: http://theincidentaleconomist.com/wordpress/planning-falacy/

Zacznijmy od tego, że nam ludziom bardzo trudno jest oszacować czas trwania zadania lub projektu programistycznego. Dlaczego?

Ludzie są z reguły słabi w szacowaniu zadań. Laureat nagrody Nobla Daniel Kahneman wraz z Amosem Tverskym zaproponowali określenie “złudzenie planowania” (ang. planning fallacy). Zgodnie z ich teorią, planowanie czasowe danego zadania związane jest ze zbyt dużym optymizmem i niedoszacowaniem potrzebnego czasu na jego realizację. Związane to jest bezpośrednio z kilkoma czynnikami:

  • Planowanie z uwzględnieniem tylko i wyłącznie najbardziej optymalnego scenariusza dla rozwiązania zadania.
  • Myślenie życzeniowe, innymi słowy – ludzie są przekonani, że ukończą dane zadanie szybko i bez problemów.
  • Prawo Brooksa: dodanie nowej osoby (lub nowych osób) do opóźnionego projektu powoduje ryzyko jeszcze większego opóźnienia.
  • Efekt skupienia: przywiązanie zbyt dużej uwagi do jednego szczegółu, co w istocie zaburza racjonalną ocenę użyteczności rozważanego rozwiązania.
  • Dysonans poznawczy: wg Wikipedii – “stan nieprzyjemnego napięcia psychicznego, pojawiający się u danej osoby wtedy, gdy jednocześnie występują dwa elementy poznawcze (np. myśli i sądy), które są niezgodne ze sobą. Dysonans może pojawić się także wtedy, gdy zachowania nie są zgodne z postawami. Stan dysonansu wywołuje napięcie motywacyjne i związane z nim zabiegi, mające na celu zredukowanie lub złagodzenie napięcia.”

Badania Standish Group z roku 2004 dla wykazały, że 71% projektów IT była niedoszacowana czasowo lub/i budżetowo, co według wyliczeń skutkuje stratami rzędu 55 miliardów USD w samych Stanach rocznie. Bent Flyvberk, ekspert ds. planowania, przeanalizował niemal 300 największych inwestycji publicznych na świecie – blisko 90% z nich było niedoszacowanych.

Continue reading

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