Czym jest Test Driven Development (TDD) ⚡ i testowanie jednostkowe (Unit Testing)? 🕹️

Test Driven Development (TDD) i Unit Testing to jedne z najważniejszych koncepcji we współczesnym programowaniu.

Dlaczego warto te koncepcje znać i stosować?

Dlaczego są tak ważne, jeżeli chcemy tworzyć łatwe do utrzymywania, pozbawione bugów projekty?

W tym odcinku odpowiadam na najważniejsze pytania związane z TDD i testowaniem jednostkowym.

[TheMallrok]

Kamilu, czy planujesz nagrać filmik na temat Wzorców Projektowych? Z tego co czytałem w internecie, pytania o wzorce pojawiają się na rozmowach rekrutacyjnych.

[piotrkrysiak]

Studiuję informatykę na Politechnice, uczę się już dość dużo języka C++, moja nauka niestety nigdy nie była systematyczne ale od pół miesiąca jest i pozostanie, na studiach będziemy szlifować C++ aktualnie działamy w obiektówce i w następnym semestrze będzie c#,
Jak myślisz jest sens zaczynać jeszcze jakiś język samemu w domu czy wyszlifować c++ na najwyższy poziom i uczyć się niedługo C# tak jak na zajęciach?

[robertkoosowski]

Czy była by możliwość nagrania filmu z TDD ale dla C++ w środowisku VS ?

[raven]

Ą ę, kęt, fejling, i takie podejście. Tdd może w idealnym świecie było by dobrym podejściem, ale na pewno nie w tym

[piotrkst]

Nie od wczoraj interesuje mnie temat poprawnych praktyk testowania kodu, regularnie szukam wiedzy na ten temat z różnych źródeł. Temat nie jest prosty i niestety materiały takie jak ten tylko to potwierdzają, bo początkujący programiści opierający na nim swoje przyszłe implementacje będą mieli problemy z poprawnym definiowaniem zarówno samych testów jak i kodu docelowego. Według mnie źle przedstawiony został sam koncept TDD (tylko kolejność zdarzeń się zgadza), a sam test funkcjonalnie pozostawia wiele do życzenia.
Po pierwsze testy poprzedzające właściwą implementację powinny weryfikować wszystkie założenia przyszłej implementacji. Na nagraniu w 9:21 mamy zielone światło, ale nie sprawdziliśmy praktycznie niczego.
Po drugie zgodzę się, że nie trzeba pisać testu per asercję, ale wciskanie 10 asercji w jeden test z kolejno (losowo?) dobranymi liczbami to jakiś kanał. Kiedy test ten zaświeci się na czerwono nie będziesz wiedział, czy powodem jest błędna zwrotka z założeń "fizz", "buzz", "fizzbuzz", czy pozostałych liczb. Minimum które należałoby zrobić, to wyodrębnić cztery testy jednostkowe weryfikujące każdy podpunkt założeń.
Po trzecie, czy pisanie 10 asercji sprawia, że czujesz się bezpiecznie z wytwarzaną implementacją? Dlaczego 10? A nie 5 lub 105? Czy nie powinno się skonstruować testu tak, aby wystarczyła jedna asercja?
- jeden test weryfikujący liczby podzielne przez 3 i niepodzielne przez 5 zwracający fizz,
- jeden test weryfikujący liczby podzielne przez 5 i niepodzielne przez 3 zwracający buzz,
- jeden test weryfikujący liczby podzielne przez 3 i 5, zwracający fizzbuzz,
- jeden test weryfikujący liczby niepodzielne przez 3 i 5, zwracający podaną liczbę.

[pecewu]

IMO ta implikacja była zbędna. Wystarczyło: i % 15 == 0