ソフトウェア開発中に、コードベースに既知の問題であるバグが存在する場合があります。テストが適切に作成されている場合、これらのバグにより、回帰/単体テストが失敗します。
私たちのチームでは、失敗したテストをどのように管理すべきかについて、常に議論があります。
REVISIT または TODO コメントを使用して、失敗したテスト ケースをコメント アウトします。
- 利点:新しい欠陥が導入されたときは常にわかりますが、既に認識している欠陥ではありません。
- 欠点: コメントアウトされたテスト ケースを再確認するのを忘れる可能性があります。つまり、欠陥が見過ごされる可能性があります。
テスト ケースは失敗したままにします。
- 利点: スクリプトが失敗すると、欠陥が存在することが常に思い出されるため、欠陥の修正を忘れることはありません。
- 短所:障害ノイズにより、新しい欠陥が導入されたときに検出が困難です。
この点に関して、ベストプラクティスとは何かを探りたいと思います。個人的には、スクリプトが通過しているかどうかを判断するには、トライステート ソリューションが最適だと思います。たとえば、スクリプトを実行すると、次のように表示されます。
- 合格率: 75%
- 失敗率 (予想): 20%
- 失敗率 (予期しない): 5%
基本的に、何らかのメタデータを使用して、(何らかの欠陥により) 失敗すると予想されるテスト ケースをマークします。これにより、テストの最後に引き続き失敗の結果が表示されますが、予期していなかった新しい失敗があるかどうかがすぐにわかります。これは、上記の 2 つの提案の最良の部分を採用しているように見えます。
これを管理するためのベストプラクティスはありますか?