W jaki sposób testy integracyjne krytykują projekt?

Czytam na blogu JB Rainsbergera o zintegrowanych testach i zastanawiam się, w jaki sposób test integracji jest trudniejszy w naszym projekcie?

Piszemy bardziej zintegrowane testy, które są większe i nie krytykują naszego projektu tak surowo, jak robią to mikrotesty

Mikrotesty mogą przyczynić się do dobrego projektu . Pisząc dobre małe testy, celowo testujesz niewielką ilość kodu i wypełniasz luki próbnymi obiektami . Prowadzi to do niskiego sprzężenia (rzeczy nie są od siebie zależne) i wysokiej spójności (rzeczy, które należą do siebie pozostają razem). W ten sposób, kiedy wrócisz i dokonasz zmian, łatwo będzie znaleźć to, co jest odpowiedzialne za to, czego szukasz, i mniej prawdopodobne jest, że popsuniesz zmiany. To nie rozwiąże całego projektu, ale może pomóc.

W tym kontekście JB Rainsberger zauważa, że ​​jeśli masz trudności z pisaniem testu jednostkowego, prawdopodobnie masz problem z projektem, który powoduje tę trudność, a zatem testy niejawnie krytykują projekt. Uważa, że ​​jest to dobra rzecz, ponieważ bez drobnych testów pomagających utrzymać architekturę w linii łatwo jest odejść od dobrych wzorców projektowych - których zintegrowane testy nie przechwycą.

Aktualizacja : jak zauważył poniżej Rainsberger, nie zamierzał, aby mikrotesty były synonimem testów jednostkowych. Podał także szczegółową odpowiedź, która może dać ci głębszy wgląd w to, co komunikował.

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.

Ma na myśli, że dobry projekt oprogramowania jest lepiej informowany przez testy jednostkowe niż testy integracyjne.

Dlatego. Pisanie testów jednostkowych zmusza do napisania kodu, który można przetestować jednostkowo. Kod testowany przez jednostkę jest lepszym projektem niż kod, który nie ma testów jednostkowych.

Testy integracyjne nie informują kodu w ten sam sposób, ponieważ testujesz tylko zewnętrzną warstwę oprogramowania, a nie wewnętrzne interfejsy łączące oprogramowanie.