新しいバグごとに単体テストを追加する
私の仕事では、バグを解決するすべての開発者が、この種のバグについて警告する新しい単体テストを追加する必要があります（再度発生する場合）。単体テストが不可能な場合（たとえば、Webページの設計の問題）、QA部門はテストケースを作成して手動でチェックする必要があります。
この背後にある考え方は、製品のリリース前に欠陥が検出されなかったのは、それを検出するための適切な単体テストがないためです。したがって、開発者はそれを追加する必要があります。
問題は、これはソフトウェア開発の方法論でよくあることなのでしょうか。このテクニックには名前がありますか？それについてもっと知りたいのですが、それを始めるためにいくつかの情報が必要です。
これはよくあることです。これをチームで使用します。すべての製品の欠陥について、開発者は問題の根本原因に関するメモを追加し、失敗するユニットテストを追加して、テストの影響分析を追加してから、チケットを開発状態にプッシュしてチェックインする必要があります。コード。
コードを本番環境にプッシュする前に、失敗するユニットテストに合格する必要があります。
これには一般的な「回帰テスト」以外の具体的な名前はないと思います。これは非常に便利で、このプロセスを開始してから製品の品質が向上し始めています。
絶対に！
単体テストが良いことであることに同意できる場合は、バグがある場合、そのコードパスをカバーする単体テストがないことがわかります。
したがって、何が起こるかというと、バグが存在することを示す単体テストを記述し、実際のバグを修正してから、単体テストに合格します。
単体テストがまったくない場合、これはプロジェクトに単体テストを導入する良い方法です。
この手法はテスト駆動開発です。次回は同様のバグを見つけることができるということではありませんが、一連の繰り返し可能なテストは常に役立ちます。ポイントは、コードの問題を特定し、それが間違っていることを証明し、それを修正し、修正が正しいことを証明したことを示すことができるということです。
思い出せない、または見つけられない引用がありますが、大まかに言って、「すべてのバグはまだ書かれていないテストです」。
回帰テストとしてそれを売り込もうとすることは、敗戦です。これらのことが頻繁に繰り返されるバグに遭遇する頻度が低いことを考えると、ほとんどの開発者は、「なぜ、単純に修正できるのに困るのですか？」
この手法はかなり一般的であり、私の意見では、最良の名前は「欠陥駆動テスト」です（私は自分でそれを思いついたのですが、この名前で説明されていました 昔 ）。
一部の人々がこれらのテストを「回帰テスト」と呼ぶのを見かけるかもしれませんが、私は個人的にこの名前を正当化するのが少し難しいと思います。 「リグレッションテスト」のやや広く定義された定義（そしておそらくこの名前にとってより意味のあるもの）は、「コードに変更を加えた後でテストを実行して、リグレッションが導入されていないことを確認する」こととCIリポジトリへのプッシュで各ブランチをテストすることはそれを満たします。