TDD 対 BDD の議論は、どちらの側を選択するかのように組み立てられることがよくあります。実際には、彼らはさまざまな質問に答えます。テスト駆動開発では、コードが開発者が意図したとおりに動作するかどうかが問われますが、動作駆動開発では、ソフトウェアが何をすべきかについてチームが同意しているかどうかが問われます。

違いを具体的にするために、各アプローチで小さな割引機能を 1 つ構築します。標準ライブラリを使用して Python 3.13 でコードを実行しました。以下の結果はその実行結果です。 BDD 部分ではメカニズムを示すために独自の小さなランナーを使用するため、実際のプロジェクトでは代わりに Cucumber などのツールを使用するか、behave を使用します。

短い答え

テスト駆動開発 (TDD) はコーディング手法です。失敗する小さなテストを作成し、最も単純なコードで合格させてから、設計を改善します。テストはコードで記述され、主に開発者によって作成されます。ケント・ベックはこの習慣を広めました。

行動駆動開発 (BDD) は、TDD から発展したコラボレーションの実践であり、Dan North がこの用語を導入しました。開発者、テスター、ビジネス関係者は、システムがどのように動作するべきかの例を平易な言葉で記述し、合意することで、それらの例を自動化できます。

TDD と BDD を並べて表示

特徴

私たちが実装するビジネス ルールは次のとおりです。 1000 個以上の注文は 10% オフになります。メンバーはこれらの注文からさらに 5% オフになります。

それは明白に聞こえるかもしれませんが、すでに曖昧です。 500 を購入したメンバーは 5% オフになりますか?文には「それらの命令」と書かれているので、そうではないものと仮定します。これはまさに、BDD が早期に明らかにするように設計された種類の質問であるため、この点に留意してください。

TDD で構築する

TDD は、red、green、refactor として知られる短いループに従います。

これらはルールごとに 1 つずつのテストです。

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)

次に、コードを 3 段階で記述し、それぞれの段階でテストを実行しました。厳密な TDD セッションでは一度に 1 つのテストが追加され、これは同じ進行を示しています。

ステージ 1: 最も単純なこと

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

ゼロを返すのはばかげているように見えますが、これはテストが実際に失敗する可能性があり、合格した 1 つのテストが「割引なし」ルールであることを証明しています。

ステージ 2: しきい値を追加する

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

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

ステージ 3: メンバーの追加とクリーンアップ

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

３人とも合格。ただし、このバージョンをよく読んでください。 500 を購入したメンバーには 5% の割引が与えられますが、これは私たちが想定していたルールの意味とは異なります。このケースをカバーしたテストはなかったため、何もフラグはありませんでした。 TDD は、テストしようと考えた動作のみを保護します。これが実際の制限であり、例についての会話が非常に重要である理由です。

なぜサイクルが重要なのか

• 赤はテストが機能することを証明します。一度も失敗したことのないテストは、何もテストしていない可能性があります。
• 緑は集中力を維持します。必要なコードのみを作成できるため、オーバーエンジニアリングを防ぐことができます。
• リファクタリングにより品質を高く保ちます。 テストにより、安全に設計を変更する自信が得られます。
• 設計に影響します。 テストが難しいコードは多くの場合、結合が強すぎるため、すぐに気づきます。

pytest チュートリアルでは、このようなテストを作成するためのより便利な方法を示し、境界値分析では、値として 999 と 1000 を選択した理由を説明しています。

BDD で構築する

BDD はツールではなく会話から始まります。多くの場合、それは スリー アミーゴ として知られる短い会議であり、製品担当者、開発者、テスターが具体的な例について話し合います。

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.

この 1 回のやり取りで、TDD コードの問題が発見されたでしょう。次に、Gherkin と呼ばれる構造化フォーマットで例を記録します。

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

チームの誰もがそれを読んで、「はい、それは正しい」または「いいえ、それは間違っています」と言うことができます。たとえ自動化しないとしても、シナリオはすでに有用な作業を行っています。

ステップをコードに接続する

ツールは、平易な言語の各行をステップ定義と呼ばれる関数に接続します。このアイデアを示すために、私たちは自分たちで小さなバージョンを作成し、最初のシナリオを実行しました。

@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

実際のツールではパラメーターが追加されるため、1 つのステップで「1000」と「500」の両方に一致し、さらにレポートが作成されます。その結果、生きたドキュメントが完成しました。これは、真実でなくなった場合に大声で失敗するシステムの平易な説明です。

良いシナリオを書く

クリックとフィールド ID を説明するシナリオは再設計のたびに壊れ、ビジネス読者はシナリオを読むのをやめてしまいます。ユーザー インターフェイスの詳細をステップ コードに保持します。これらのシナリオは、テスト ケースとテスト シナリオの例に近いもので、ユーザー受け入れテストでもよく使用されます。

両方を一緒に使用する

この 2 つは、「アウトサイドイン」ワークフローに自然に適合します。

1. チームは動作について合意し、BDD シナリオを作成します。まだ何も存在しないため、失敗します。
2. 開発者は TDD を使用して、必要な小さなユニットを構築します。
3. 単体テストは合格し、最終的にはシナリオも合格します。
4. すべては CI/CD パイプライン で実行されます。

それぞれを適切なレベルに保ちます。重要な動作についてはいくつかのシナリオを用意し、詳細については迅速な単体テストを多数用意する必要があります。 単体テストと統合テストに関するガイドでは、バランスについて説明しています。

ツール

それぞれをいつ使用するか

TDD は次の場合に適しています。

• 価格設定、解析、権限などの複雑なロジックを作成しているとします。
• 失敗したテストで最初にバグを再現できるため、バグを修正することになります。
• あなたは頻繁に変更されるコードに取り組んでいます。

BDD は次の場合に適切に適合します。

• ビジネスルールは複雑であり、誤解は高くつくものです。
• 技術者ではない人でもシナリオを読んで議論するでしょう。
• いくつかのチームは、何かがどのように動作するかについての共有定義を必要としています。

次のような場合には、どちらもやりすぎになる可能性があります。使い捨てのプロトタイプを作成している場合、または不明確な技術的アイデアを検討している場合。多くの開発者は、最初にスパイクを付けてから、テストで書き直します。エンジニアリング外部の誰もシナリオを検討しないのであれば、BDD ツールも投資としては不十分です。その場合、適切な名前を付けた単純なテストの方が簡単です。

よくある間違い

• BDD をテスト ツールとして扱う。 コラボレーションのない Cucumber は、単なる冗長なテスト作成方法です。
• TDD でのテスト実装。 プライベートな詳細に関連付けられたテストは、リファクタリングのたびに中断されます。
• リファクタリング手順をスキップします。 乱雑なコードの上でテストに合格します。
• コード​​の後に​​テストを記述し、それを TDD と呼びます。 これでも便利ですが、設計のフィードバックが失われます。
• UI シナリオを書きすぎると、 UI シナリオが遅くなり不安定になります。 不安定なテストを参照してください。
• カバレッジの数字を追う。 この例が示すように、優れたカバレッジでも、誰も考慮していない行動は依然として見逃されます。

まとめ

TDD は正しいものを構築するのに役立ち、BDD は正しいものを構築するのに役立ちます。私たちの割引の例では、両方の側面が示されました。コードはすべてのテストに合格しましたが、簡単な会話で間違った仮定が明らかになりました。次の小さな機能で試してみてください。コードを作成する前に、同僚と具体的な例を 3 つ書き、失敗するテストを一度に 1 つずつ作成します。

よくある質問

学び続ける