Programowanie sterowane testami to metodologia tworzenia oprogramowania polegająca na testowaniu najpierw, co oznacza, że wymaga napisania kodu testowego przed napisaniem rzeczywistego kodu, który będzie testowany. Słowami Kenta Becka:
Styl polega na napisaniu kilku wierszy kodu, następnie wykonaniu testu, a nawet lepiej napisaniu testu, który nie zostanie uruchomiony, a następnie napisaniu kodu, który go uruchomi.
Po zastanowieniu się, jak napisać jeden mały fragment kodu, zamiast tylko kodować, chcemy uzyskać natychmiastową informację zwrotną i poćwiczyć „koduj trochę, trochę testuj, koduj trochę, testuj trochę”. Dlatego od razu piszemy dla niego test.
Zatem TDD to niskopoziomowa metodologia techniczna, której programiści używają do tworzenia czystego kodu, który działa.
Behavior-Driven Development to metodologia, która została stworzona w oparciu o TDD, ale przekształciła się w proces, który nie dotyczy tylko programistów i testerów, ale dotyczy całego zespołu i wszystkich ważnych interesariuszy, technicznych i nietechnicznych. BDD zaczęło od kilku prostych pytań, na które TDD nie odpowiada: ile testów powinienem napisać? Co właściwie powinienem przetestować, a czego nie? Który z testów, które napiszę, będzie w rzeczywistości ważny dla firmy lub dla ogólnej jakości produktu, a które są po prostu moim przeprojektowaniem?
Jak widać, takie pytania wymagają współpracy między technologią a biznesem. Interesariusze biznesowi i eksperci dziedzinowi często mogą powiedzieć inżynierom, jakiego rodzaju testy brzmią tak, jakby byłyby przydatne - ale tylko wtedy, gdy są to testy wysokiego poziomu, które dotyczą ważnych aspektów biznesowych. BDD nazywa takie testy biznesowe „przykładami”, na przykład „powiedz mi przykład, jak ta funkcja powinna działać poprawnie”, a słowo „test” zastrzega dla niskopoziomowych testów technicznych, takich jak sprawdzanie poprawności danych lub testowanie integracji API. Ważną częścią jest to, że chociaż testy mogą być tworzone tylko przez programistów i testerów, przykłady mogą być zbierane i analizowane przez cały zespół dostarczający - przez projektantów, analityków i tak dalej.
W jednym zdaniu jedną z najlepszych definicji BDD, jakie do tej pory znalazłem , jest to, że BDD polega na „prowadzeniu rozmów z ekspertami w danej dziedzinie i używaniu przykładów w celu uzyskania wspólnego zrozumienia pożądanego zachowania i odkrywania nieznanych”. Część odkrywcza jest bardzo ważna. W miarę jak zespół dostarczający zbiera więcej przykładów, zaczyna coraz lepiej rozumieć domenę biznesową, a tym samym zmniejsza swoją niepewność co do niektórych aspektów produktu, z którym ma do czynienia. Wraz ze spadkiem niepewności wzrasta kreatywność i autonomia zespołu wykonawczego. Na przykład mogą teraz zacząć sugerować własne przykłady, których użytkownicy biznesowi nie uważali za możliwe z powodu braku wiedzy technicznej.
Teraz rozmowy z ekspertami biznesowymi i dziedzinowymi brzmią świetnie, ale wszyscy wiemy, jak często kończy się to w praktyce. Swoją przygodę z technologią rozpocząłem jako programista. Jako programiści uczymy się pisać kod - algorytmy, wzorce projektowe, abstrakcje. Lub, jeśli jesteś projektantem, uczysz się projektowania—Organizuj informacje i twórz atrakcyjne interfejsy. Ale kiedy otrzymujemy pracę na poziomie podstawowym, nasi pracodawcy oczekują od nas „dostarczania wartości klientom”. A wśród tych klientów może być np. ... bank. Ale nie mogłem wiedzieć prawie nic o bankowości - poza tym, jak skutecznie zmniejszyć saldo konta. Musiałbym więc jakoś przetłumaczyć to, czego się ode mnie oczekuje, na kod ... Musiałbym zbudować pomost między bankowością a moją wiedzą techniczną, jeśli chcę wnieść jakąkolwiek wartość. BDD pomaga mi zbudować taki most na stabilnym fundamencie płynnej komunikacji między zespołem dostarczającym a ekspertami dziedzinowymi.
Ucz się więcej
Jeśli chcesz poczytać więcej o BDD, napisałem książkę na ten temat. „Pisanie doskonałych specyfikacji” bada sztukę analizowania wymagań i pomoże ci nauczyć się budować wspaniały proces BDD i wykorzystywać przykłady jako podstawową część tego procesu. Książka omawia wszechobecny język, zbiera przykłady i tworzy z przykładów tak zwane specyfikacje wykonywalne (testy automatyczne) - techniki, które pomagają zespołom BDD dostarczać świetne oprogramowanie na czas i w ramach budżetu.
Jeśli jesteś zainteresowany kupnem „Pisania świetnych specyfikacji” , możesz zaoszczędzić 39% dzięki kodowi promocyjnemu 39nicieja2 :)