1

私は python/django 出身です。

私は BDD について読んでいて、なぜそれが TDD よりも優れているのかを調べました。しかし、私の頭に浮かんだ疑問のほとんどは、BDD を実行するための理想的な方法は何でしょうか? ということでした。単体テストの作成を除外しますか? 統合テストを行うことを除外しますか? BDD を実装するための答えや整理された順次パスが見つかりませんでした。

TDD を介してDjango ポーリング アプリケーションを設計するには、次のようにします。

  1. モデルのテストを書き、テストをパスさせます。

  2. フォームのテストを書き、それを通過させます。

  3. ビューのテストを作成し、合格させます。

  4. カスタム テンプレート タグとミドルウェアのその他のテストを作成し、それらをパスさせます。

  5. ビューを書き始めたときから、統合テストを徐々に書き続けます。

私の読書に基づいて、django polls アプリケーションを設計する場合、従わなければならないプロセスは次のとおりです。

  1. ガーキン構文でシナリオを書く

  2. ステップを書く

  3. 手順では、UI 応答 (統合) に基づいて、おそらくいくつかのアサーション (ユニット) を使用します。

  4. わからない、次に何を/どのように行うか、またはパート3さえも正しい.

私の混乱を解消し、簡単な概要を提案してください。

どうすれば先に進むことができるか教えてください。django polls applicationを実行するときに、BDD を試行するための順次アプローチは何でしょうか。

（この質問が主観的なものではないことを願っています.SOはそれを尋ねるのに適した場所です。そうでなければ、私を殺さないでください.）

4

1 に答える 1

1

BDD にはいくつかの特定の技術的プラクティス (シナリオに基づく自動化、アウトサイド イン開発、単体テストなど) が含まれますが、その主な目標はプロジェクト内のコミュニケーションを改善することです (非技術関係者を含む)。

利害関係者と話し合って、仕様を例の形で収集することから始めます。これにはさまざまな方法がありますが、ここで最も重要なことは話すことです。それらの議論の間、ガーキンに有効なシナリオを書くように強制しないでください。許容基準 (つまり、システムが従わなければならない制約) と共に、予想される動作をキャプチャするだけです。

次に、シナリオを形式化して、理想的には、ビジネス担当者と一緒にレビューします。このフェーズは、仕様に対するあなた (およびチーム) の理解を検証するため、興味深いものです。多くの場合、自分が間違った思い込みをしていたことに気付くことになります :)

一連の仕様 (機能) を定義し、それらの優先順位に合意したら、実際の開発プロセスを開始できます。

私の通常の作業方法は次のようなものです。

  1. シナリオを実行します。最初のステップが未定義であることを確認してください。
  2. そのステップのステップ定義を追加します。
  3. もう一度実行すると、実装がないために失敗することがわかります。
  4. 欠落しているシステムの動作について、単体テスト/仕様を 1 つ記述します。
  5. テストを実行し、失敗することを確認します。
  6. 合格させてください。
  7. コードをリファクタリングします。
  8. シナリオを再実行する
    • ステップが失敗した場合は、#4 に進みます
    • ステップが定義されていない場合は、#2 に進みます
    • そうでなければ、このシナリオは終了です。次のシナリオに進んでください :)

これは、基本的に、アウトサイドイン開発です。お気づきかもしれませんが、ステップ 4 から 7 は通常の TDD サイクルです。このワークフローの利点の 1 つは、TDD サイクルが適切にガイドされることです。次に何をすべきかを考える必要はありません。シナリオ障害スタック トレースのおかげで、次に必要な実際の動作が明示的に表示されます。

もちろん、これは物事を行うための1 つの方法です。決まったものは何もなく、物事を適応させることができます。

于 2012-09-21T08:03:50.860 に答える