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.