単体テストの手続き型コードは効果的ですか？
現在のプロジェクトでは、ユニットテストを開発サイクルに組み込んで、コードに染み込んでいるように見える一定量のバグを回避したいと考えています。問題は、スパゲッティコードが95％パーセントの手続き型であり、ユニットテストを一度も行ったことがないことです（ユニットテストのすべての経験は、OOPコード）で行われました）。
簡単に言えば、私の質問は、現在のコードベースでユニットテストを進めるか、アプリケーションが適切なOOPフレームワークに移行されるまで延期することをお勧めしますか？
PS：この質問を言語にとらわれないスタイルにしようとしたが、問題のアプリケーションでPHPとjavascriptを使用すると、この質問に答えることができるより具体的な回答を提供するのに役立つと思うこのようなアプリケーションで最も発生します。
ユニットテストはオブジェクトでうまく機能します。特に、モックオブジェクトなどの多くの豪華な機能を提供し、より良いテストをより速く作成するのに役立ちます。
これは言われています手続き型コードベースでユニットテストを行うことを禁止するものはありません。 OOPでは、ほとんどのユニットテストは、いくつかのパラメーターをパラメーターに渡し、結果または特定のタイプの例外のいずれかを期待することによってメソッドをテストします。これは、手続き型コードでも実行できます。それだけメソッドをテストする代わりに、関数をテストします。
次のことを行う必要があることに注意してください。
テストする必要がある機能と不要な機能を分離します。 OOPではこれは簡単です。呼び出し側が直接アクセスすることはできないため、プライベートメソッドをテストする必要はありません。おそらく、手続き型コードでは、いくつかの関数はこのようなものであり、テストを必要としません。
グローバルスコープについて考えます。問題はOOP=にも存在しますが、スパゲッティコードをテストする必要があると言った場合、このコードを書いた人は、グローバルスコープを使いすぎるなどの悪い癖がある可能性があります。いくつか変更などのクレイジーなこと
$_GETまたは$_POST配列関数内。関数外のコードを処理します。これはより複雑なケースですが、それでも可能です。どちらか
require_once何が起こるかを確認するページとob_start/ob_get_clean、またはテストスイートからHTTPリクエストを実行し、HTMLを解析して応答を分析します。これは実際にはUIテストではありません。ここでは、ページのボタンが左側または右側に表示されるか、リンクが大きな赤い大文字か小さな青いものかは問題ではありません。重要なのはDOMを介していくつかのHTML要素を見つけるであり、それらのコンテンツを期待されるものと比較することです。応答コードをテストします。
require_once出力バッファリングは有効ですが、Webアプリケーションがエラーを処理する方法もテストする必要があります。たとえば、予想されるテスト結果が404 Not Foundの場合、応答を知るためにHTTPリクエストを実行する必要があります。
アプリケーションが適切なOOPフレームワークに移行されるまで延期することをお勧めします
いくつかの自動テストを実施しますbefore後でではなく、別のプラットフォームに移行します。その後ではなく、移行の実行中にさらにテストを追加します。これらのテストが「統合テスト」または単体テストである場合は、自分で決定する必要がありますが、通常、両方の種類にお気に入りのxUnitテストフレームワークを使用できます。
単体テストを開始する最も効果的な方法は、最も頻繁に発生する、またはコストが最も高いエラーのクラスを識別することです。次に、それらのエラーを対象とするテストを作成します。
これらのテストを実装する方法は、パラダイムと言語によって異なります。ユニットテストを実行する能力に影響を与える最大の要素は、コードの品質です。より少ないので、使用されるパラダイム。ユニットテストは、コードの「ユニット」を個別にテストすることを忘れないでください。コードの「ユニット」を分離する能力に影響を与えるものは、テストを難しくします。
- グローバルの使用
- 副作用
- 密結合コード
- 正しく結合されていないコード
- 多数の条件文
- 不適切に設計された「ユニット」
これらすべては、言語パラダイムよりもテストの難易度に大きな影響を与えます。
コードの一部を自動的にテストできる状況があるときはいつでも、ユニットテストが効果的です。したがって、問題は手続き型コードを効果的に単体テストすることができないかどうか、問題はこのコードを単体テストできるかどうかです。それは、それが読み取る状態と設定する状態によって異なります。理想的には両方に対する答えはゼロですが、ゼロでない場合でもテストできます。
いつものように、コードが正しいという確信と、その確信を得るためのコストを比較検討する必要があります。単体テストの利点の一部は依存関係を明示的に識別することであり、その意味では、OOPコードと比較して、手続き型コードを単体テストする方がより効果的です。