IT eSky.pl

RSS

Jak robić bugfixy w BDD

Rozwijanie nowych funkcjonalności przy pomocy BDD to bardzo czysty proces. Nasze testy zawsze wyprowadzamy z wymagań użytkownika. Rozbijamy te wymagania na kilka poziomów przy pomocy zagnieżdżonych kontekstów. Porządkujemy je w dobrze zorganizowaną strukturę, przypominającą niemalże dokumentację dla użytkownika końcowego – i opowiadającą spójną historię naszego systemu.

Niestety, gdy naprawiamy błędy, ten porządek lubi się rozsypywać.

Nie pozwól poprawkom błędów popsuć spójności Twojej specyfikacji

Gdy naprawiamy błąd, operujemy na bardzo niskim poziomie. Wychodzimy od konkretnego, szczegółowego opisu problemu i próbujemy go debugować, by odkryć jego przyczynę. Patrzymy przez to zazwyczaj z bardziej skupionego na szczegółach, wyjętego z kontekstu punktu widzenia niż wtedy, kiedy wychodzimy od wysokopoziomowych wymagań. W efekcie wykazujemy tendencję do pisania równie skupionych na szczegółach testów.

Nie powinniśmy jednak zapominać, że błędy nigdy nie istnieją w próżni. Błąd wynika albo z brakującego wymagania, albo z dziury w naszej implementacji jednego z istniejących wymagań. Nie ma czegoś takiego jak „niezależny” błąd.

Dlatego nie powinniśmy NIGDY traktować bugfixów, ani testów do tych bugfixów, jako niezależnych patchy. Naprawiając błąd, zawsze powinniśmy myśleć w jaki sposób zintegrować brakujący test z istniejącą specyfikacją, tak by pozostawała spójna.

Przyjrzyjmy się tej idei w działaniu:

Istniejący system

Kodujemy panel kontrolny dla statku kosmicznego. Typowym kompromisem na takich statkach jest rozdział energii pomiędzy poszczególnymi podsystemami. Nasze działka plazmowe i tarcze są tak energożerne, że nie możemy puścić napędu na więcej niż 30% jego maksymalnej mocy gdy są one włączone.

Oczywiście, kontrolowanie wszystkich tych systemów ręcznie jest niewygodne, dodajemy więc do naszego panelu kontrolnego ładny przełącznik, który automatycznie ustawi generator mocy w jeden z dwóch trybow: bitewny (z włączonym uzbrojeniem i napędem przyciętym do 30%) albo rejsowy (z uzbrojeniem wyłączonym i bez przycinania napędu).

Spójrzmy na odpowiadający tym wymaganiom fragment testów naszego panelu kontrolnego:

Testy przechodzą i możemy wyruszać ku bezkresnym otchłaniom wszechświata.

Niestety, podczas naszego pierwszego spotkania z kosmicznymi piratami, odkrywamy że w systemie jest bug.

Błąd

Nasz strzelec pokładowy lubi siać plazmowymi pociskami przy dźwiękach epickiej bitewnej muzyki. Podkręca głośniki na maksa i… nasze tarcze nagle się wyłączają! Ledwo uchodzimy z życiem.

Sprawdzamy nasz system debuggerem i okazuje się, że nasz nowy Bombastyczny Subwoofer MK III pożera więcej mocy niż nam się wydawało. Nie może być uzywany równocześnie z tarczami.

Naiwny bugfix

Ponieważ jesteśmy w kontekście niskopoziomowych szczegółów, łatwo jest wpaść w pułapkę i „naprawić” naszą suitę testową w sposób dokładnie odpowiadający opisowi problemu, który właśnie odkryliśmy:

Wprawdzie taki test pozwala nam załatać błąd, ale wydaje się zupełnie nie na swoim miejscu. Nie opowiada wraz z resztą suity spójnej historii.

Czysty bugfix

Jeśli zastanowimy się przez chwilę, zauważymy, że blokowanie głośników nie powinno być bezpośrednio powiązane z tarczami. Jest częścią bardziej ogólnego, wysokopoziomowego scenariusza (który już się w naszej specyfikacji znajduje):

Teraz wszystko wskakuje na swoje miejsce, tworząc spójną specyfikację.

Spójna historia a nie przypadkowa lista wyjątków

W powyższym przykładzie łatwo jest dostrzec problem, może się więc on wydawać nieco sztuczny. Jednak w prawdziwym kodzie, takie testy nie na swoim miejscu nie zawsze rzucają się w oczy. Jeśli nie podejmiemy świadomego wysiłku by je znaleźć i poprawnie skonsolidować z resztą suity, będzie się ona z biegiem czasu degenerować, zmieniając się z uporządkowanej specyfikacji w przypadkową listę różnych przypadków brzegowych i wyjąków.

Taka suita niewątpliwie będzie działć i wyłapywać błędy regresyjne, nie opowiada jednak spójnej historii, niepotrzebnie utrudniając zrozumienie systemu.


A jak to wygląda w Twoim przypadku? Spotkałeś się z podobnym problemem podczas naprawiania błędów w procesie BDD? Podziel się swoją opinią w komentarzach poniżej!