Chapter 02無料公開

BDD とは

Woo YooWaan
Woo YooWaan
2021.05.30に更新

😁 python の behave ベースに説明してきます 😌

とは

2003年、Dan North さんによって命名されたものらしい

It was originally named in 2003 by Dan North as a response to test-driven development (TDD), including acceptance test or customer test driven development practices as found in extreme programming.

アジャイルの手法でもあるし、繰り返しのサイクルの中でも役に立つ手法らしい

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

ステークスホルダーとの要求・ユーザーストーリーを明確にする事にも役に立つし、エンジニア以外の人とも話すものに使えるかDDD界隈のユビキタス言語としてもいけるものらしい

※ 詳細は参考リンクの behave を読んでください

BDDを構成するものとは

BDD Practice を実行・実現しながら、 Outside-in の観点・関係を解決して , Gherkin language で記述すると BDD と言えるらしい

BDD Practice

BDDのプラクティスは以下のようなことが実現出来ていることが望ましい
(これの実現には、前提条件として設計力と実装力が求められる)

behaveより

  • ステークホルダーの要求を実装するためにゴールを明確にする
  • フィーチャーを用いて必要な実装機能引き出す・相互理解を進める
  • 開発の外部性を利用してステークスホルダーをプロセスに参加させる
  • アプリケーションまたは単体機能で例を示す
  • テストから迅速なフィードバックや回帰テストを自動化する
  • 振舞から責務を明確にすることが出来て、機能単位の正確性を考察・理解する
  • 振舞の結果判定から、スコープ範囲の問題かそれ以外の副作用かを判断する
  • モックを利用してコラボレーション可能にする

wiki ※1 より

  • 何処から始まるか?理解可能にする(Where to start in the process)
  • テストが必要・不必要の判断を可能にする(What to test and what not to test)
  • 一つにどれだけテストが必要か理解可能にする(How much to test in one go)
  • テストと呼ぶものは何かを明確にする(What to call the tests)
  • テストを失敗した理由を理解可能にする(How to understand why a test fails)

Outside-in

BDDはビジネスバリュードリブンなので、ソフトウェア開発やコードが何と利害関係があるかや、それぞれのモジュールや機能の関係性を理解高める側面があります。
これによりステークホルダーとの利害関係や価値についての外部からの視点で解決が出来て、コードについて洞察が深まり、YAGNIな効果の側面もあります。

Gherkin language

Gherkin というDSLを利用することで、開発者とQAエンジニア間で要件が明確になります。
合わせて、DSLでテスト内容を明確に記述できます

📝 雑まとめ

  • ステークホルダーやQAエンジニアのコミュニケーションに便利
  • コードの可読性・保守性の向上に使える

次のチャプターから実際に環境を整備して、実際に動かしていきます

参考リンク