Rozległy TAK z TDD (i kilkoma wyjątkami)
Kontrowersyjne w porządku, ale twierdzę, że każdemu, kto odpowie „nie” na to pytanie, brakuje podstawowej koncepcji TDD.
Dla mnie odpowiedź brzmi tak, jeśli postępujesz zgodnie z TDD. Jeśli nie, to nie jest wiarygodną odpowiedzią.
DDD w TDD
TDD jest często cytowany jako mający główne zalety.
- Obrona
- Zapewnienie, że kod może się zmienić, ale nie jego zachowanie .
- Pozwala to na bardzo ważną praktykę refaktoryzacji .
- Zyskujesz to TDD, czy nie.
- Projekt
- Ci określić, co należy zrobić coś, jak należy to zachowuje się przed wprowadzeniem go.
- Często oznacza to bardziej świadome decyzje wdrożeniowe .
- Dokumentacja
- Zestaw testowy powinien służyć jako dokumentacja specyfikacji (wymagań).
- Zastosowanie testów do tego celu oznacza, że dokumentacja i implementacja są zawsze w spójnym stanie - zmiana na jedną oznacza zmianę na drugą. Porównaj z zachowaniem wymagań i projektu na osobnym dokumencie Word.
Oddziel odpowiedzialność od wdrożenia
Jako programiści strasznie kusi myślenie o atrybutach jako o czymś istotnym, a getters i seter o czymś w rodzaju kosztów ogólnych.
Ale atrybuty są szczegółami implementacji, podczas gdy setery i gettery są umownym interfejsem, który faktycznie powoduje, że programy działają.
O wiele ważniejsze jest przeliterowanie, że obiekt powinien:
Pozwól swoim klientom zmienić swój stan
i
Pozwól swoim klientom zapytać o jego stan
następnie w jaki sposób ten stan jest faktycznie przechowywany (dla którego atrybut jest najczęstszy, ale nie jedyny sposób).
Test taki jak
(The Painter class) should store the provided colour
jest ważny dla części dokumentacji TDD.
Pisząc test, fakt, że ostateczna implementacja jest trywialna (atrybut) i nie przynosi żadnej korzyści obronnej, nie powinien być dla ciebie nieznany.
Brak inżynierii w obie strony ...
Jednym z kluczowych problemów w świecie rozwoju systemu jest brak inżynierii w obie strony 1 - proces rozwoju systemu jest podzielony na niepowiązane podprocesy, których artefakty (dokumentacja, kod) są często niespójne.
1 Brodie, Michael L. „John Mylopoulos: szycie nasion modelowania koncepcyjnego”. Modelowanie koncepcyjne: podstawy i zastosowania. Springer Berlin Heidelberg, 2009. 1-9.
... i jak TDD to rozwiązuje
Jest to część dokumentacji TDD, która zapewnia, że specyfikacje systemu i jego kodu są zawsze spójne.
Najpierw zaprojektuj, a później zaimplementuj
W TDD najpierw piszemy test akceptacji zakończony niepowodzeniem, a dopiero potem kod, który pozwala im przejść.
W BDD wyższego poziomu najpierw piszemy scenariusze, a następnie je przekazujemy.
Dlaczego warto wykluczyć seterów i getterów?
Teoretycznie jedna osoba może napisać test w TDD, a druga wdrożyć kod, który go zdaje.
Więc zadaj sobie pytanie:
Czy osoba pisząca testy dla klasy wspomina getters i setter.
Ponieważ metody pobierające i ustawiające są publicznym interfejsem dla klasy, odpowiedź brzmi oczywiście tak , lub nie będzie możliwości ustawienia ani zapytania o stan obiektu.
Oczywiście, jeśli najpierw napiszesz kod, odpowiedź może nie być tak jednoznaczna.
Wyjątki
Istnieją pewne oczywiste wyjątki od tej reguły - funkcje, które są wyraźnymi szczegółami implementacyjnymi i wyraźnie nie są częścią projektu systemu.
Na przykład metoda lokalna „B ()”:
function A() {
// B() will be called here
function B() {
...
}
}
Lub funkcja prywatna square()tutaj:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Lub dowolna inna funkcja, która nie jest częścią publicinterfejsu wymagającego pisowni w projekcie komponentu systemu.