Czy testy BDD są testami akceptacyjnymi?

BDD "testy" istnieją na wielu różnych poziomach szczegółowości, aż do początkowej wizji projektu. Większość ludzi wie o scenariuszach. Kilka osób pamięta, że BDD zaczęło się od słowa "Powinien" jako zamiennik "testu" Junita - jako zamiennik TDD. Powodem, dla którego umieszczam "testy" w cudzysłowach, jest to, że BDD nie jest tak naprawdę testowaniem; koncentruje się na znalezieniu miejsc, w których występuje brak lub niedopasowanie zrozumienia.

Z powodu tego skupienia, rozmowy są o wiele ważniejsze niż narzędzia BDD.

Powtórzę to jeszcze raz. rozmowy są o wiele ważniejsze niż narzędzia BDD.

Testy akceptacyjne w rzeczywistości nie upoważniają do rozmów i zazwyczaj działają z założenia, że testy, które piszesz, są odpowiednimi testami. W BDD Zakładamy, że nie wiemy, co robimy (i prawdopodobnie nie wiemy, że nie wiemy). Dlatego używamy takich rzeczy jak "Given, When, Then" - aby może prowadzić rozmowy na temat scenariuszy i / lub przykładów na poziomie jednostki. (Są to dwa poziomy, które większość ludzi zna - odpowiednik testów akceptacyjnych i testów jednostkowych - ale rośnie skala).

Nie nazywamy ich "testami akceptacyjnymi", ponieważ nie możesz poprosić osoby biznesowej "proszę pomóż mi z moim testem akceptacyjnym". Spojrzą na Ciebie dziwnym, Zezowatym spojrzeniem, a potem odrzucą Cię jako tę dziwaczną dziewczynę. 93% z Was tego nie chce.

Try " I ' d chciałbym porozmawiać z tobą o scenariuszu gdzie..."zamiast tego. Albo: "czy możesz podać mi przykład?"Oba są dobre. Nazywanie ich "testami Akceptacyjnymi" zaczyna sprawiać, że ludzie myślą, że faktycznie wykonujesz testy, co oznaczałoby, że wiesz, co robisz i po prostu chcesz się upewnić, że to zrobiłeś. W tym momencie rozmowy skupiają się na tym, jak szybko można wyciągnąć niewłaściwą rzecz, zamiast na tym, że wyciągasz niewłaściwą rzecz.

And you ' re getting the wrong wypad. Naprawdę, szczerze, jesteś.Nawet jeśli myślisz, że nie jesteś, to tylko dlatego, że nie rozumiesz ignorancji drugiego rzędu. Nie wiesz, że nie wiesz, i to jest w porządku, tak długo, jak znajdziesz miejsca, gdzie Może wiedzieć, że nie wiesz. (Nie znajdziesz ich wszystkich. Nie pozwól, aby paradoks kategoryzacji powstrzymywał cię w nocy.)

Jedynym sposobem, aby naprawdę to zrobić, jest uzyskanie wszystkich wymagań z góry, i wiesz, co się dzieje, gdy spróbuj tego. Zgadza się. To Wodospad. Pamiętasz Nadgodziny? Praca w weekend? Siedem lat, w których ani jedna rzecz, którą stworzyłeś, nie trafiła do produkcji? Jeśli chcesz tego uniknąć, masz tylko jedną szansę: założyć, że się mylisz, porozmawiać o tym, aby być mniej błędnym, a następnie zaakceptować, że jesteś nadal w błędzie i tak to zrób. Pisanie testów zbyt wcześnie oznacza, że masz nawet więcej szansy na błąd, a teraz trudniej się zmienić i wszyscy myślą masz racje a premier mierzy Ci predkosc i teraz jestes zobowiazany sie mylic przez kolejne 2 tygodnie. I-co gorsza-zaraz sprawdzisz, że też się mylisz.

Jeszcze raz. rozmowy są o wiele ważniejsze niż narzędzia BDD.

Proszę, nie skupiaj się na narzędziach. Narzędzia są tylko mechanizmem do przechwytywania rozmów i upewniania się, że są odtwarzane w kodzie. Scenariusze nie zastępują rozmów, już niż karta indeksowa 3 x 5 jest zamiennikiem wymagań.

Powiedziawszy to, jeśli musisz zacząć od narzędzia, umieść Slim za Fitnesse, aby mógł działać lovely Given / When / Thens bez bałaganu ze stołami i oprawami Fit. GivWenZen jest oparty na Slim i obu z nich skał. FitSharp jest odpowiednikiem dla tych z Was w przestrzeni. NET. Lub po prostu użyj Cucumber, lub SpecFlow, lub zapukaj trochę niestandardowej DSL * , która wykona zadanie dobrze dla lat.

Transparentność :* ja to napisałem. I kawałki JBehave. Szkoda, że nie nazwaliśmy tego "Dont-concentrate-on-BDD-tools-Behave". Mogę być mocno zaangażowany w inne kawałki BDD. Plus Dan North kupi mi piwo, jeśli uda mi się przekazać tę wiadomość, Więc to nie jest do końca bezstronna Rada.

Bez względu na to - miej już rozmowy. To tylko ludzie. Idź pogadać.