Czy robię to, prawda? Jeśli nie to co dokładnie muszę zmienić
Trudno powiedzieć na podstawie tego krótkiego opisu, ale podejrzewam, że nie robisz tego dobrze. Uwaga: nie mówię, że to, co robisz, nie działa lub jest w jakiś sposób złe, ale nie robisz TDD. Środkowe „D” oznacza „Driven”, testy napędzają wszystko, proces rozwoju, kod, projekt, architekturę, wszystko .
Testy mówią ci, co napisać, kiedy to napisać, co napisać dalej, kiedy przestać pisać. Mówią o projekcie i architekturze. (Projekt i architektura wyłaniają się z kodu poprzez refaktoryzację.) TDD nie polega na testowaniu. Tu nawet nie chodzi o pisanie testów: TDD polega na tym, aby testy cię poprowadziły, napisanie ich jako pierwszego jest po prostu niezbędnym warunkiem do tego.
Nie ma znaczenia, czy faktycznie zapisujesz kod, czy masz go w pełni rozwinięty: piszesz (szkielety) kodu w głowie, a następnie piszesz testy dla tego kodu. To nie TDD.
Porzucenie tego nawyku jest trudne . Naprawdę bardzo ciężko. Wydaje się to szczególnie trudne dla doświadczonych programistów.
Keith Braithwaite stworzył ćwiczenie, które nazywa TDD tak, jakbyś to rozumiał . Składa się z zestawu zasad (opartych na trzech regułach TDD wuja Boba Martina , ale o wiele surowszych), których należy ściśle przestrzegać i które mają na celu bardziej rygorystyczne stosowanie TDD. Działa najlepiej z programowaniem par (aby twoja para mogła upewnić się, że nie łamiesz zasad) i instruktorem.
Reguły są następujące:
- Napisz dokładnie jeden nowy test, najmniejszy test, jaki możesz wskazać w kierunku rozwiązania
- Zobacz, jak zawodzi; niepowodzenia kompilacji liczą się jako awarie
- Wykonaj test z (1), pisząc najmniejszy możliwy kod implementacyjny w metodzie testowej .
- Przeprowadź refaktoryzację, aby usunąć duplikację, i w inny sposób, aby poprawić projekt. Bądź ostrożny przy użyciu tych ruchów:
- chcesz nowej metody - poczekaj do czasu refaktoryzacji, a następnie… utwórz nowe (nietestowe) metody, wykonując jedną z tych czynności i w żaden inny sposób:
- preferowane: wykonaj Wyodrębnij metodę z kodu implementacji utworzonego zgodnie z (3), aby utworzyć nową metodę w klasie testowej, lub
- jeśli musisz: przenieść kod implementacji zgodnie z (3) do istniejącej metody implementacji
- chcesz nowej klasy - poczekaj do czasu refaktoryzacji, a następnie… utwórz klasy nietestowe, aby zapewnić miejsce docelowe dla metody przenoszenia bez żadnego innego powodu
- zapełnij klasy implementacji metodami, wykonując metodę Move, i żadną inną metodą
Zazwyczaj doprowadzi to do bardzo różnych projektów niż często praktykowana „pseudo-TDD” polegająca na wyobrażaniu sobie w głowie, jaki powinien być projekt, a następnie pisanie testów w celu wymuszenia tego projektu, wdrożenie projektu, który już przewidziałeś przed napisaniem testy ”.
Kiedy grupa ludzi wdraża coś w rodzaju gry w kółko i krzyżyk za pomocą pseudo-TDD, zwykle kończy się to bardzo podobnymi projektami, obejmującymi jakąś Boardklasę z tablicą 3 × 3 Integers. I przynajmniej część programistów faktycznie napisała tę klasę bez testów, ponieważ „wiedzą, że będą jej potrzebować” lub „będą potrzebować czegoś, na co mogliby napisać swoje testy”. Jednak, gdy zmusisz tę samą grupę do zastosowania TDD tak, jak chcesz, często kończą się szeroką różnorodnością bardzo różnych projektów, często nie wykorzystując niczego nawet zdalnie podobnego do Board.
Czy jest jakiś sposób na stwierdzenie, czy napisany test jest wystarczający?
Gdy pokrywają wszystkie wymagania biznesowe. Testy są kodowaniem wymagań systemowych.
Czy dobrą praktyką jest pisanie testu pod kątem bardzo prostej funkcjonalności, która może być równoważna 1 + 1 = 2, czy może to tylko overplay?
Znowu masz to odwrotnie: nie piszesz testów funkcjonalności. Piszesz funkcjonalność do testów. Jeśli funkcjonalność umożliwiająca zdanie testu jest trywialna, to świetnie! Właśnie spełniłeś wymagania systemowe i nie musiałeś nawet ciężko nad tym pracować!
Czy dobrze jest zmienić funkcjonalność i odpowiednio sprawdzić, czy zmieniają się wymagania?
Nie. Odwrotnie. Jeśli wymaganie się zmienia, zmieniasz test, który odpowiada temu wymaganiu, obserwujesz, jak się nie udaje, a następnie zmieniasz kod, aby przejść pomyślnie. Testy są zawsze najważniejsze.
Trudno to zrobić. Potrzebujesz dziesiątek, może setek godzin celowej praktyki , aby zbudować coś w rodzaju „pamięci mięśniowej”, aby dojść do punktu, w którym, gdy zbliża się termin i jesteś pod presją, nawet nie musisz o tym myśleć , a robienie tego staje się najszybszym i najbardziej naturalnym sposobem pracy.