私は現在、既存のPHPプロジェクトに取り組んでいます。現在のコード設計はそれほど良くなく、バグが山積みになり始めています。ですから、私が欲しいのは、より信頼性の高いものにするために包括的なテストスイートを追加することです。
PHP Unitで記述されたユニットテストはすでにいくつかありますが、テストカバレッジはそれほど良くありません。このプロジェクトは、実際にはTDDやテストを多用するプロセスには従いません。可能な限り、すべてをテストしてもらいたいと思います。しかし、問題は、既存のコードのテストを追加できるかどうかわからないことです。先ほど申し上げたように、コード構造はそれほど良くないので、テストを追加するのは非常に面倒で難しいかもしれません。
このようなプロジェクトに単体テストを追加するためのより良い方法はありますか？それとも、プロジェクトを書き直す必要がありますか？たぶんモジュールごと？
既存のアプリケーションに単体テストを追加しようとしたときに発生する問題のほとんどは、通常、そのアプリがその機能を効果的にテストできるクラスとメソッドに十分に分割していないために発生します。
これは、実際にはTDDだけでなく、アプリケーションを開発するときにテストを作成することの良い習慣の主な利点の1つです。テストでは、明確な目的と可能な限り少ない副作用を備えた簡潔なメソッドを作成する必要があります。
完全な書き直しが究極の解決策になるでしょうが、それを行う時間とエネルギーがあるとは思えません。その上、そのような行動は私が完全に必要ではないかもしれません！
正直なところ、私の経験では、最善のアプローチは、各モジュールのテストを一度に作成し、必要に応じてリファクタリングを開始することです。たとえば、ユーザー登録や管理ビットなどのコア要素から始めて、さらに進んでください。
大変な作業のように思えるかもしれませんが、作業が無駄になっているように感じるかもしれませんが、長期的には、これらのテストにより、アプリケーションのデバッグに費やす時間が大幅に削減されます。
参考文献：
テストできるもののテストを開始しただけです。データを処理して結果を返すクラスは、テストを作成して機能させ、クラスのごく一部をテストできることを検証できます。開始するのは大変でしたが、現在、3000以上のテストで約45％のコードカバレッジがあります。これらのテストは現在、人々がコードをリファクタリングするときにエラーをキャッチします。
テストを容易にするモジュールとクラスを分離しようとしました。一部のテストは、コンストラクターやパブリックインターフェイスなどをテストするだけで、変更すると問題が発生する可能性があります。
新しいバグが発見されたら、最初にバグを説明するためのテストを作成し、次にコードを変更してテストを解決します。これにより、テストが前進し続けます。
毎日、結果が有望になり始めるまで、より大きなテストベースとより完全なコードカバレッジで、いくつかのテストを追加しました。途中のある時点で、私たちのテストは、人々がいくつかのレガシーインターフェースを壊すコードを追加または変更したときに作成される問題を実際に見つけました。これは、自動テストでの最初の良い勝利でした。古い入力ファイルの手動テストなしで発見されたため、テストされなかった可能性があります。
既存のコードベースにテストを追加しようとする場合は、十分に注意してください。Andreiが指摘したように、タスクは非常に大きく、テストが最初から統合されている場合にTDDが最適に機能します。
コア機能にテストを追加し、残りの部分を開発者がテストすることで、昔ながらの方法でバグを修正してみてください。