Biblioteki BDD, takie jak Spock i jGiven pomagają tworzyć deskryptywne testy bez obciążenia jakim jest Gherkin. Tyle, że jeśli chcemy zachować choć szczątki koncepcji BDD powinniśmy je pisać językiem… biznesowym. W tym artykule pokażemy jak łatwo z tym popłynąć i jak sobie z tym poradziliśmy.

Bebechy na wierzchu

Za przykład posłuży nam domena usługowa, którą wykorzystujemy na wystąpieniach JUG-owych (więcej w tym poście). Wyobraźmy sobie, że tworzymy test dla use case’a wyceniającego usługi. Jeśli używamy komend i handlerów pierwsze bezwysiłkowe podejście może wyglądać tak:

Niby cacy – w given ustawiamy, jaką komendę wykonamy, w when ją wykonujemy, w then sprawdzamy niezmienniki. A gdzie język biznesu? Gdzieś tam się przebija,  ale nie ma rewelacji… Komendy i handlery to za wiele dla większości „ludzi biznesu”.

Jak wykorzystać Fixture

Więc jak schować to co nieprzyjemne… Wspomóż się Fixture! Dobrze użyte fixture jest w stanie pięknie przypilnować odpowiedniego poziomu abstrakcji. Każda interakcja z nim powinna odbywać się tylko z wykorzystaniem słownictwa biznesowego. Końcowy efekt może być taki:

W tym przypadku wykorzystujemy wbudowany w Spock’a koncept Fixture, który rozumie przez niego klasę całego testu rozszerzającą Specification. Jeśli więc przypilnujemy SRP możemy śmiało użyć pól klasy jako domknięcia przypadku testowego i wypełnić je wszystkie w sekcji given. Wtedy w sekcji when wołamy  metodę  serviceIsFinished()  bez parametrów. Jej implementacja wygląda tak:

Proste? Proste. Wysiłek jest minimalny a efektem jest test, który można pokazać biznesowi. W następnym poście pokażemy jak zrobić podobną rzecz w C# z wykorzystaniem biblioteki naszego autorstwa, gdzie ponadto mamy możliwość konwersji testów na tekst (po to, żeby stały się jeszcze bardziej przystępne dla biznesu).

Podsumowanie

Czy podobnie jak my uważasz, że tego typu refaktoryzacja jest wartościowa? A może było dla Ciebie oczywiste, że tak się robi? Zapraszamy do komentowania i dzielenia się przemyśleniami.

Kategorie: Testing

5 Komentarzy

Sebastian Rabiej · Styczeń 25, 2018 o 08:30

Świetny artykuł. Im bardziej przejrzyste testy tym lepiej, nie tylko dla biznesu ale również dla komfortu programisty.

Witek · Styczeń 25, 2018 o 16:28

Największą czytelność dla „biznesu” dało dodanie kolumny .z actionType której przed zmianami nie było (a mogła by być)

    Szymon Janikowski · Luty 14, 2018 o 08:38

    Dzięki za tę uwagę! Rzeczywiście ta różnica mogła odciągać od głównej tezy artykułu. Już poprawione.

Kamil J · Luty 7, 2018 o 19:22

Czy opisywanie np. każdej z sekcji jak w tym przykładzie:
https://github.com/KamilJedrzejuk/carservice/blob/master/workshop/src/test/groovy/example/vehicleworkshop/workorder/domain/WorkOrderSpec.groovy

daje jakiś większy sens biznesowy?

    Szymon Janikowski · Luty 14, 2018 o 09:14

    Opisywanie to też niezły sposób na czytelność. Ale pozostaje pytanie jak łatwo zapewnić, że to co jest w opisie jest zawsze zgodne z kodem pod spodem.
    Poza tym przy takim podejściu, w kodzie testu wciąż widoczne są sprawy czysto techniczne. Pojawia się „Dto”, jest wywoływane „build”, wykorzystywana jest „Fasada”. To co my sugerujemy w poście, to pozbycie się z testu wszystkiego co techniczne. To w tym pomagają nam nazwane ‚biznesowo’ funkcje i pola całego fixture.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *