多くの開発者が、新しいプロジェクトを開始するときにどのスタイルのテストを使用するかについて意見が分かれているのを目にします。この特定のスタイルを他のスタイルよりも選択する理由を知りたい.
4 に答える
BDD と TDD はお互いを排除していません。BDDは、要件分析から始めて、ソフトウェア開発全体に取り組んでいると思います。TDD は純粋に実装に関連するものであり、実際には開発者の個人的な作業手法です。
私は通常、原則としてアウトサイド インを使用します。それをTDDと呼ぶかBDDと呼ぶかは、私にとってはそれほど重要ではありません。
これが意味することは、実装したい機能の最も重要な部分から始めて、そこから作業するということです。多くの場合、これはユーザー インターフェイスですが、そうである必要はありません。最も重要な領域がサービス操作またはバックグラウンド プロセスである場合があり、そこから始めます。
Test Double を使用して、定義したクラスがその環境とどのように相互作用するかを定義し、機能を実装するにつれて、これらの Test Double によって定義された抽象化をどんどん実装します。
つまり、私は BDD の考え方から始めて、いわばコール スタックを下っていくにつれて、TDD に向かってどんどん進んでいると言えるでしょう。
TDD と BDD は、実際には心の状態です。私が見ているように、TDDでは、この時点でこの値がどうあるべきかについて多くの重点が置かれています.BDDは、もちろん値とそれらをどのように取得したかをテストします.この状態にある場合、アプリケーションのこの部分はどうすればよいでしょうか。
私はBDDスタイルでTDDを行うことを学びました。そのすべては本当にあなたがあなたの思考をどのように行うかという問題です。
多くの人が、TDDはテストに関するものだと思って間違いを犯しました。したがって、BDDは、テストよりも動作を強調することで混乱を最小限に抑えるために作成されました。