testing - プロジェクト要件が変化し続ける場合、テストケースを使用する必要がありますか？

Question

私のプロジェクトの要件は頻繁に変更され続けています。テストケースを維持することは非常に不便になりました。それでもテストケースを使用することをお勧めしますか？または、この問題を処理するための良い方法はありますか？

Answer 1

コードを変更する必要がある場合は、テストハーネスを維持することがこれまで以上に重要だと思います。テストハーネスはドキュメントの形式です。

Answer 2

これは、単体テストを行うことの苦痛の一部です。あなたはそれに固執する必要があります。

1. 要件が落ち着くと、はるかに良い場所になります。
2. テストがないと、より脆弱になります。急激な変化が発生すると、誤って壊れてしまう可能性が非常に高くなります。
3. あなたが今テストを断念するならば、あなたはそれを再び取り戻さない可能性が高いです…。

Answer 3

私が100％のテストカバレッジを私に納得させようとする人に私が言うもう一つの議論は聖杯です。

プロジェクトの要件は、（これが非常に小さなプロジェクトでない限り）まったく変更されません。結局のところ、物理法則によって定められたいくつかの仮定、主張、制限が常にあります:)

要件を確認し、それらを層に分割することを提案します。ティア1の要件は、ティア2の要件よりも変更される可能性が低くなります。これにより、揮発性の低いパーツに焦点を当てることができます。最終的に、要件プロデューサーは疲れます（交換、退屈）。

開発者は体調が悪い必要があります。要件を迅速に変更すると、スパゲッティコードが取得されます。テストハーネスはある程度スパゲッティにすることができますが、それは本当に彼らにとって命の恩人です。そのようなプロジェクト組織に適合させることは非常に重要です。

Answer 4

この質問に「TDD」のタグを付けたので、テスト駆動開発を介して変更された要件を実装する方法を考えてください。新しい要件の場合は、新しい機能がないことを示す失敗したテストを作成します。要件が変更された場合、機能が元の状態にあることを（合格することで）示すテストがすでにある可能性があります。だから、あなたの開発を試してみてください。合格したテストを変更して、新しい動作が必要になるようにし（失敗します）、変更された動作を実装して合格させます。

Answer 5

設計をレビューして、要件の変更に伴って頻繁に変更される部品があるかどうかを確認する機会を利用する必要があります。現在の設計に変更を加えて、パーツを2つのパーティションに移動することもできます。1つはほとんど同じままで、もう1つはほとんど変更されます。

要件が変更されたときに新しいコード/クラスを追加するだけでよいように、変更する部分を分離できる場合があります。