BDD: Pierwsze kroki

Zaczynam od BDD i oto moja historia:

Feature: Months and days to days
    In order to see months and days as days
    As a date conversion fan
    I need a webpage where users can enter
    days and months and convert them to days.

Mam parę wątpliwości ...

Czy powinienem napisać scenariusze przed czymkolwiek zakodować, czy powinienem najpierw napisać scenariusz, a następnie napisać kod, napisać scenariusz ponownie, a następnie napisać kod itd.?

Jeśli powinienem wcześniej napisać scenariusze, czy moje kroki mogą zostać zatwierdzone, a kod produkcyjny nadal nie jest gotowy?

Kiedy powinienem dokonać refaktoryzacji mojego kodu? Po zakończeniu funkcji lub po wdrożeniu każdego scenariusza?

Z tej historii wnioskuję, że sam kodujesz.

Zwykle celem BDD jest umożliwienie rozmów, szczególnie między biznesem a programistami, aby zespół mógł mieć pewność, że doszli do porozumienia. Lubimy też dołączać testerów, ponieważ mogą wykryć, kiedy przegapiliśmy scenariusze.

Jeśli robisz to sam, weź gumową kaczkę i wyjaśnij kaczce zachowanie swojej aplikacji. Podaj kilka przykładów tego, jak powinno to działać. To będą twoje scenariusze.

Na początek proponuję nie automatyzować tych scenariuszy. Możesz je zapisać, jeśli chcesz. Pamiętaj, że wyniki biznesowe, które udostępniasz kaczce, są na odpowiednim poziomie, aby je wyrazić. Powinieneś mieć pojęcie o tym, jak zachowuje się aplikacja, i możesz ręcznie uruchomić scenariusze. Lubię traktować wszystko, co jeszcze nie działa, jak błąd . I mają czasem zaczęło się automatyzacji, ale tylko wtedy, gdy wiem bardzo dobrze, jak działa system, jestem zaznajomiony z narzędzi, a interfejs jest dobrze poznany. Nawet wtedy często muszę go trochę przerabiać, kiedy piszę kod.

Na niższym poziomie powiedz kaczce, jak zachowa się każda klasa. Podaj kilka przykładów. Gumowe kaczki doskonale rozumieją język techniczny. Teraz masz BDD na poziomie jednostki, czyli testy jednostkowe. Cykl refaktora czerwono-zielonego odbywa się tutaj. (Nie muszę już tak często refaktoryzować, ponieważ myślę o obowiązkach moich klas, pisząc je w języku zorientowanym na biznes, i to i tak wypada dość pięknie. Ale ja robię to już od jakiegoś czasu. Jeśli tak, to jest OK.)

Nie zmieniaj tego za bardzo. Nadal chcemy otrzymywać opinie na temat naszego kodu, ponieważ zawsze są rzeczy, których nie wiemy, a których nie wiemy . Doskonałość jest tutaj twoim wrogiem. Spraw, aby był wystarczająco dobry, uczynić go czytelnym, a następnie przejdź dalej. Jeśli chcesz zrobić coś idealnego, aby wprowadzić dalsze zmiany, zrób to, gdy dokonasz dalszych zmian.

Jeśli masz możliwość uzyskania informacji zwrotnej na temat swoich scenariuszy od interesariuszy biznesowych, ale nie są z Tobą usatysfakcjonowani, możesz wysłać im scenariusze, jak tylko to napiszesz, i zanim je zautomatyzujesz. Możesz także wysłać makietę interfejsu użytkownika, aby mogli oni skorelować słowa z działaniami. Dzięki temu nie wyprzedzaj kodowania zbyt daleko. Pracuj z założeniem, że to, co już zrobiłeś, jest złe i musisz uzyskać informacje zwrotne, aby dowiedzieć się, jak to zrobić.

Jako ostatnia wskazówka, nie frazuj historii z punktu widzenia użytkownika (scenariusze, tak, ale nie historie). To nie są historie użytkowników. Prawdopodobnie powinno to brzmieć:

In order to attract people to my website
As @thom
I want users to easily convert months and days to days.

W każdym razie szukasz jakiegoś celu na wyższym poziomie. Pomoże to również wyciągnąć potrzebne możliwości. Powodzenia i przepraszam za bardzo długi post.

Czy powinienem napisać scenariusze przed czymkolwiek zakodować, czy powinienem najpierw napisać scenariusz, a następnie napisać kod, napisać scenariusz ponownie, a następnie napisać kod itd.?

Oba będą działać. Wybierz jedno.

To nie ma większego znaczenia.

Im więcej masz scenariuszy, tym więcej projektu możesz zrobić z góry.

Im więcej masz scenariuszy, tym więcej czasu zajmuje wykonanie zadania.

Kiedy powinienem dokonać refaktoryzacji mojego kodu? Po zakończeniu funkcji lub po wdrożeniu każdego scenariusza?

Nie. Refaktoryzujesz, kiedy trudno jest zaprojektować następny scenariusz.

Używaj czasowników opisowych

Feature: CONVERT Months and days to days

Nie podejmuj decyzji projektowych w opowiadaniach [„Potrzebuję strony internetowej” to decyzja projektowa]

As a date conversion fan
I want to convert days and months into days

Wykorzystuj cele wartości biznesowej w opowieściach

So that [some business reason]

Zanim zaczniesz pisać, napisz jak najwięcej funkcji i historii. Historie informują się nawzajem , wpływają na funkcje i informują o projekcie.

Refaktoryzuj po każdej historii. Refaktor czerwono-zielony.