Niezwykle krótka wersja: mniejsze testy, ponieważ uruchamiają mniejsze części systemu, naturalnie ograniczają to, co programiści mogą napisać, a to stwarza okazję do ostrzejszej (łatwiejszej do zauważenia / trudniejszej do zignorowania) opinii. Dodam, że niekoniecznie prowadzi to do lepszego projektowania, ale raczej stwarza możliwość wcześniejszego zauważenia ryzyka projektowego.
Po pierwsze, aby wyjaśnić, kiedy mówię „mikrotest”, mam na myśli „mały test” i nic więcej. Używam tego terminu, ponieważ nie mam na myśli „testu jednostkowego”: nie chcę angażować się w debaty na temat tego, co stanowi „jednostkę”. Nie obchodzi mnie to (przynajmniej nie tutaj / teraz). Dwie osoby prawdopodobnie łatwiej zgodzą się na „małą” niż na „jednostkę”, więc stopniowo postanowiłem przyjąć „mikrotest” jako nowy standard tego pojęcia.
Większe testy, czyli testy, w których działają większe części systemu w części „akcji”, nie krytykują projektu w sposób tak wyraźny ani tak kompletny jak mniejsze testy. Wyobraź sobie zestaw wszystkich baz kodu, które mogłyby przejść daną grupę testów, co oznacza, że mógłbym reorganizować kod i nadal przechodziłby te testy. W przypadku większych testów ten zestaw jest większy; w przypadku mniejszych testów ten zestaw jest mniejszy. Innymi słowy, mniejsze testy bardziej ograniczają projekt, więc mniej projektów może je spełnić. W ten sposób mikrotesty mogą bardziej krytykować projekt.
Mówię „bardziej surowo”, aby wyczarować obraz przyjaciela, który mówi wprost to, czego nie chcesz słyszeć, ale musisz usłyszeć, i który krzyczy na ciebie, aby przekazać pilność w sposób, który inni mogą nie czuć się komfortowo robić. Z drugiej strony zintegrowane testy zachowują spokój i wskazują na problemy głównie wtedy, gdy nie masz już czasu ani energii, aby je rozwiązać. Zintegrowane testy ułatwiają zamiatanie problemów projektowych pod dywanikiem.
W przypadku większych testów (takich jak testy zintegrowane) programiści zwykle mają kłopoty z powodu niechlujstwa: mają wystarczającą swobodę pisania splątanego kodu, który jakoś przechodzi testy, ale ich zrozumienie tego kodu szybko zanika, gdy przechodzą do następnego zadania , a inni mają nadmierną trudność z odczytaniem splątanego wzoru. Na tym polega ryzyko polegania na zintegrowanych testach. Przy mniejszych testach (takich jak mikrotesty) programiści mają zwykle problemy z nadmierną specyfikacją: nadmiernie ograniczają testy, dodając nieistotne szczegóły, zwykle kopiując / wklejając z poprzedniego testu, i robiąc to stosunkowo szybko malują się w kąt. Dobre wieści: O wiele łatwiej i bezpieczniej jest mi usuwać zbędne szczegóły z testów kilka godzin lub dni po ich napisaniu, niż odkrywam splątany kod produkcji miesiące lub lata po jego napisaniu. W miarę pomyłek nadmierne specyfikowanie powoduje coraz bardziej oczywiste uszkodzenia, a programista alertów widzi wcześniej, że muszą to naprawić. Uważam to za siłę: zauważam problemy wcześniej i naprawiam je, zanim problemy te zduszą naszą zdolność do dodawania funkcji.