新しいバグごとに単体テストを追加する

私の仕事では、バグを解決するすべての開発者は、このタイプのバグについて警告する新しいユニットテストを追加する必要があります（再び発生する場合）。単体テストが不可能な場合（たとえば、Webページのデザインの問題）、QA部門はテストケースを作成して手動でチェックする必要があります。

この背後にある考え方は、製品のリリース前に欠陥が検出されなかった場合、それを検出するための適切な単体テストがないためであるということです。そのため、開発者が追加する必要があります。

問題は、これはどのソフトウェア開発方法論でも一般的ですか？このテクニックには名前がありますか？私はそれについてもっと学びたいのですが、それから始めるにはいくつかの情報が必要です。

これは非常に一般的です。これをチームで使用します。開発者は、生産の欠陥ごとに、問題の根本原因に関するメモを追加し、失敗した単体テストを追加し、コードをチェックインするためにチケットを開発状態にプッシュする前にテスト影響分析を追加する必要があります。

コードを実稼働環境にプッシュする前に、失敗した単体テストに合格する必要があります。

これには一般的な「回帰テスト」以外の特定の名前はないと思います。これは非常に便利であり、このプロセスを実行し始めてから製品の品質が向上し始めています。

絶対に！

ユニットテストが良いことであることに同意できれば、バグがある場合、そのコードパスをカバーするユニットテストが欠落していることに気付くでしょう。

起こるべきことは、バグが存在することを示す単体テストを作成し、実際のバグを修正すれば、単体テストに合格することです。

単体テストがない場合、これは単体テストをプロジェクトに導入するための良い方法です。

この手法はテスト駆動開発です。次回同様のバグを見つけることができるということではありませんが、繰り返し可能なテストのスイートは常に役立ちます。ポイントは、コードの何が問題なのかを特定し、それが間違っていることを証明し、修正し、修正が正しいことを証明したことを示すことができるということです。

思い出すことも見つけることもできない引用がありますが、おおまかに言うと、「すべてのバグはまだ書かれていないテストです。」

回帰テストとしてそれを販売しようとすることは、負けた戦いです、私見。これらの事柄が繰り返しバグをキャッチする頻度が低いことを考えると、ほとんどの開発者は「わざわざ簡単に修正できるのに、なぜわざわざ」と言うでしょう。

この手法は非常に一般的であり、私の意見では、「Defect Driven Testing」が最良の名前です（私は自分で思いついたので、ずっと前にこの名前で説明されていました）。

これらのテストを「回帰テスト」と呼ぶ人もいますが、個人的には、この名前を正当化するのはやや難しいと感じています。「回帰テスト」のやや広めの定義（および、おそらくこの名前の方がはるかに意味のある定義）は、「コードに変更を加えた後にテストを実行して、リグレッションが発生していないことを確認する」とCIです。リポジトリへのプッシュ時に各ブランチをテストし、それを満たします。