Debata TDD kontra BDD często jest przedstawiana jako wybór strony. W rzeczywistości odpowiadają na różne pytania. Rozwój oparty na testach pyta, czy kod działa zgodnie z zamierzeniami programisty, podczas gdy rozwój oparty na zachowaniu pyta, czy zespół w ogóle zgadza się co do tego, co oprogramowanie powinno w ogóle robić.

Aby różnica była konkretna, przy każdym podejściu tworzymy jedną małą funkcję rabatową. Uruchomiliśmy kod w Pythonie 3.13, korzystając ze standardowej biblioteki, a poniższe wyniki pochodzą z tego uruchomienia. Część BDD wykorzystuje nasz własny mały moduł uruchamiający do pokazania mechanizmu, więc prawdziwy projekt korzystałby z narzędzia takiego jak Cucumber lub zamiast tego zachowywałby się.

Krótka odpowiedź

Programowanie oparte na testach (TDD) to praktyka kodowania. Piszesz mały test, który kończy się niepowodzeniem, przeprowadzasz go za pomocą najprostszego kodu, a następnie ulepszasz projekt. Testy są pisane w kodzie i głównie przez programistów. Kent Beck spopularyzował tę praktykę.

Rozwój oparty na zachowaniu (BDD) to praktyka współpracy, która wyrosła z TDD, a Dan North wprowadził ten termin. Programiści, testerzy i ludzie biznesu uzgadniają przykłady zachowania systemu, zapisane prostym językiem, a przykłady te można następnie zautomatyzować.

TDD kontra BDD obok siebie

Funkcja

Oto zasada biznesowa, którą wdrożymy: Zamówienia 1000 lub więcej otrzymują 10% zniżki. Członkowie otrzymują dodatkowe 5% zniżki na te zamówienia.

Może to brzmieć jasno, ale jest już niejednoznaczne. Czy członek wydający 500 otrzyma 5% zniżki? W zdaniu jest napisane „te rozkazy”, więc zakładamy, że nie. Należy o tym pamiętać, ponieważ jest to dokładnie ten rodzaj pytań, które BDD ma za zadanie stawiać na wczesnym etapie.

Zbuduj go za pomocą TDD

TDD podąża za krótką pętlą znaną jako czerwony, zielony, refaktor:

Oto nasze testy, po jednym dla każdej reguły:

class DiscountTests(unittest.TestCase):
    def test_no_discount_below_1000(self):
        self.assertEqual(discount(999, False), 0)

    def test_ten_percent_from_1000(self):
        self.assertEqual(discount(1000, False), 100)

    def test_member_gets_extra_five_percent(self):
        self.assertEqual(discount(1000, True), 150)

Następnie napisaliśmy kod w trzech etapach, po każdym przeprowadzając testy. Ścisła sesja TDD dodaje jeden test na raz, co pokazuje ten sam postęp:

Etap 1: najprostsza rzecz

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

Zwracanie zera wygląda głupio, ale dowodzi, że testy mogą w rzeczywistości zakończyć się niepowodzeniem, a jedynym testem, który przechodzi, jest zasada „braku rabatu”.

Etap 2: dodaj próg

def discount(total, is_member):
    if total >= 1000:
        return total * 0.1
    return 0

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

Etap 3: dodaj członków i posprzątaj

def discount(total, is_member):
    rate = 0.1 if total >= 1000 else 0
    if is_member:
        rate += 0.05
    return round(total * rate, 2)

# 3 tests, 0 failed

Wszystkie trzy przechodzą. Ale przeczytaj uważnie tę wersję. Daje członkowi wydającemu 500 5% zniżki, co nie jest tym, co zakładaliśmy, że ta zasada oznacza. Żaden test nie obejmował tego przypadku, więc nic go nie oznaczyło. TDD chroni tylko zachowanie, które miałeś przetestować. To jest prawdziwe ograniczenie i powód, dla którego rozmowy o przykładach są tak ważne.

Dlaczego cykl ma znaczenie

• Czerwony oznacza, że test działa. Test, który nigdy nie zawiódł, może niczego nie testować.
• Ekologia pozwala Ci się skoncentrować. Piszesz tylko taki kod, jaki jest potrzebny, co pomaga uniknąć nadmiernej inżynierii.
• Refactor utrzymuje wysoką jakość. Testy dają pewność, że można bezpiecznie zmienić projekt.
• Ma to wpływ na projekt. Kod, który jest trudny do przetestowania, jest często zbyt ściśle powiązany, co można zauważyć od razu.

Nasz samouczek dotyczący testów Pythona pokazuje wygodniejszy sposób pisania takich testów, a analiza wartości granicznych wyjaśnia, dlaczego jako wartości wybraliśmy 999 i 1000.

Zbuduj go za pomocą BDD

BDD zaczyna się od rozmowy, a nie od narzędzi. Często jest to krótkie spotkanie zwane trzema amigosami, podczas którego specjalista ds. produktu, programista i tester omawiają konkretne przykłady:

Tester:  What about a member spending 500?
Product: Good question. No discount. It has to reach 1000 first.
Dev:     And exactly 1000 counts?
Product: Yes, 1000 or more.

Ta jedna wymiana wyłapałaby problem w naszym kodzie TDD. Następnie zapisują swoje przykłady w ustrukturyzowanym formacie zwanym Ogórkiem:

Feature: Order discounts

  Scenario: Member reaches the discount threshold
    Given a member with a cart worth 1000
    When they view the amount to pay
    Then the amount to pay is 850

  Scenario: Member below the threshold gets no discount
    Given a member with a cart worth 500
    When they view the amount to pay
    Then the amount to pay is 500

Każdy w zespole może to przeczytać i powiedzieć „tak, to prawda” lub „nie, to źle”. Nawet jeśli nigdy tego nie zautomatyzujesz, scenariusz wykonał już pożyteczną pracę.

Łączenie kroków z kodem

Narzędzia łączą każdą linię w prostym języku z funkcją zwaną definicją kroku. Aby pokazać pomysł, sami napisaliśmy małą wersję i uruchomiliśmy pierwszy scenariusz:

@step("a member with a cart worth 1000")
def given(ctx):
    ctx["cart"] = Cart(is_member=True)
    ctx["cart"].add(1000)

@step("they view the amount to pay")
def when(ctx):
    ctx["amount"] = ctx["cart"].payable()

@step("the amount to pay is 850")
def then(ctx):
    assert ctx["amount"] == 850

# ok Given a member with a cart worth 1000
# ok When they view the amount to pay
# ok Then the amount to pay is 850

Prawdziwe narzędzia dodają parametry, dzięki czemu pojedynczy krok może odpowiadać zarówno „1000”, jak i „500”, plus raportowanie. Rezultatem jest żywa dokumentacja: prosty opis systemu, który głośno zawodzi, jeśli przestaje być prawdziwy.

Pisanie dobrych scenariuszy

Scenariusze opisujące kliknięcia i identyfikatory pól psują się przy każdym przeprojektowaniu, a czytelnicy biznesowi przestają je czytać. Zachowaj szczegóły interfejsu użytkownika w kodzie kroku. Scenariusze te są bliskimi kuzynami przykładów z przypadku testowego a scenariusza testowego i często są używane także w testach akceptacyjnych użytkownika.

Używanie obu razem

Obydwa w naturalny sposób pasują do przepływu pracy „z zewnątrz do wewnątrz”:

1. Zespół uzgadnia zachowanie i pisze scenariusz BDD. To się nie udaje, bo jeszcze nic nie istnieje.
2. Deweloper używa TDD do budowy potrzebnych małych jednostek.
3. Testy jednostkowe przechodzą pomyślnie i ostatecznie także scenariusz.
4. Wszystko działa w twoim potoku CI/CD.

Utrzymuj każdy na właściwym poziomie. Powinieneś mieć kilka scenariuszy ważnych zachowań i wiele szybkich testów jednostkowych dla szczegółów. Nasz przewodnik po testowaniu jednostkowym i integracyjnym opisuje równowagę.

Narzędzia

Kiedy używać każdego z nich

TDD sprawdza się dobrze, gdy:

• Piszesz złożoną logikę, taką jak ustalanie cen, analizowanie lub uprawnienia.
• Naprawiasz błąd, ponieważ możesz go odtworzyć najpierw za pomocą testu zakończonego niepowodzeniem.
• Pracujesz nad kodem, który będzie często się zmieniać.

BDD sprawdza się dobrze, gdy:

• Reguły biznesowe są złożone, a nieporozumienia kosztowne.
• Osoby nietechniczne naprawdę przeczytają i omówią scenariusze.
• Kilka zespołów potrzebuje wspólnej definicji zachowania czegoś.

Może to być przesada, gdy: piszesz jednorazowy prototyp lub badasz niejasny pomysł techniczny. Wielu programistów najpierw wykonuje skoki, a następnie przepisuje je za pomocą testów. Narzędzia BDD są również słabą inwestycją, jeśli nikt poza inżynierią nigdy nie będzie patrzył na scenariusze. W takim przypadku zwykłe testy o dobrych nazwach są prostsze.

Typowe błędy

• Traktowanie BDD jako narzędzia testowego. Ogórek bez współpracy to po prostu szczegółowy sposób pisania testów.
• Testowanie implementacji w TDD. Testy powiązane z prywatnymi szczegółami psują się podczas każdego refaktora.
• Pomijanie kroku refaktoryzacji. Otrzymujesz pozytywne testy na bałaganie w kodzie.
• Pisanie testów po kodzie i wywoływanie go TDD. Jest to nadal przydatne, ale tracisz opinię o projekcie.
• Pisanie zbyt wielu scenariuszy interfejsu użytkownika. Stają się one powolne i niestabilne. Zobacz testy niestabilności.
• Pogoń za liczbami. Dobry zasięg wciąż pomija zachowania, których nikt nie brał pod uwagę, jak pokazuje nasz przykład.

Podsumowanie

TDD pomaga zbudować właściwą rzecz, a BDD pomaga zbudować właściwą rzecz. Nasz przykład rabatowy pokazał obie strony: kod przeszedł wszystkie testy, a już prosta rozmowa ujawniła błędne założenie. Wypróbuj to w swojej następnej małej funkcji. Zanim napiszesz jakikolwiek kod, napisz ze współpracownikiem trzy konkretne przykłady, a następnie zbuduj go po jednym teście, który zakończy się niepowodzeniem.

Najczęstsze pytania

Ucz się dalej