1

TDD / BDDは理想的であり、時間が限られているため、機能を実装する前に常に100％のテストカバレッジを持ち、常にテストを作成できるとは限りません。それでは、厳しいスケジュールの下で十分にテストされたプロジェクトを作成するためのアプローチは何ですか。

私の最初の考えは次のとおりです。

  1. RSpecを使用した受け入れテスト
  2. 発達
  3. 1に戻る

受け入れテスト/開発サイクルを数回繰り返した後、追加します

  1. 統合テスト

最後に、手動テストのためにQAに発送します。バグが見つかった場合は、追加します。

  1. ユニットテスト

上記のワークフローは妥当だと思いますか？

4

1 に答える 1

6

免責事項：私はテストに感染しています

これは、一方の信頼ともう一方の短期間の配信速度の間のスライドスケールです。両方を持つことはできません。右にスライドすると、より速く発送できます。最適な位置は、コンテキスト（チームのスキル、プロジェクトの不確実性/リスク、組織の文化、スケジュールなど）によって異なります。

上記のプロセスの概要については、間違って読んでいる可能性があります。速度の単体テストを切り取っているようです。つまり、TDDなしでATDDを実行します。

それがあなたが向かっているところなら、私は次のリスクを見ます

  • 受け入れテストは分厚いです：何かが失敗したことを教えてくれますが、欠陥の特定には役立ちません。同じ受け入れテストが無数の理由で失敗する可能性があります/複数のシステムテストが同じバグで失敗する可能性があります。原因を突き止めるのに多くの時間を失う可能性があります。焦点を絞った単体テストは、問題がどこにあるかを即座に正確に教えてくれるはずです。時間の経過とともに、受け入れテストの失敗のデバッグに費やされた時間は、焦点を絞ったテストを作成しないことによって節約された時間を超過する可能性があります
  • 受け入れテストは遅い：単体テストと比較して、5分で実行できる分厚いテストはほんの一握り（楽観的）です。同時に何千ものマイクロテストを実行できます。これが役立つ理由は、単体テストにより、何かを壊したコード変更に近いフィードバックがより速く得られるためです。実行には時間がかかるため、通常の傾向として、受け入れテストの実行回数は最小限に抑えられます。アプリのバックを壊した正確なコード変更を特定するためにより多くの時間が費やされました。
  • 受け入れテストは完全ではありません。テストスイートの実行時間が実行不可能になるため、すべての小さなエッジケースをカバーすることはできません。バグは、これらのテストされていない場所で繁殖する可能性があります。

最後に、IMHOの受け入れ/システムテストは、防御の最後のレベルである必要があります。最初ではありません。チームがコード品質の問題に苦しんでいるのを見てきました。チームはコード品質に真摯に取り組んでおらず、すべてをキャッチするためにシステムテストに依存しています。上で述べたように、これはあなた自身をだましています。TDDは、コード品質により直接的な影響を及ぼします。ATDDは、何かが壊れている/顧客にとって「受け入れられない」ことを通知するだけです。そうは言っても、チームの規律と経験の適切な組み合わせによっては、短期的にはうまくいくかもしれません。私がそれに賭けないというだけです。

単体テストにかかる時間を短縮したい場合は、チームと一緒に座って、重要/重点分野/モジュールを定義します。TDDでそれらを成し遂げましょう。

于 2012-08-22T05:22:03.210 に答える