単体テスト作成の自動化

ユニットテストケースの作成を自動化するために使用できるいくつかの戦略は何ですか？少なくともまともなテストケーススケルトンを生成できるようにするには、各クラスでどの側面を検討する必要がありますか？

包括的な自動ソリューションは実用的ではないことがわかりますが、少なくともスケルトンを作成することで、テストの作成を少しスピードアップしたいと思います。私はコード例を探しているのではなく、おそらくどこから始めたらいいか、このようなことをした例がいくつかあるので、彼らがどのようにアプローチし、何が可能かを見ることができます。

特に、PHPで単体テストスケルトンを作成する方法に興味があります。これは、たとえば完全なタイプヒンティングなど、他の言語が提供するすべてのツールを提供するものではありません。

戦略とスケルトンは、生成するテストの種類、探しているカバレッジの種類、作業している言語/環境に大きく依存します。

CやJavaなどの言語の場合、クラスシグネチャを読み取り、標準のコーナーケースのテストを自動的に生成するテストジェネレーターを作成するのは非常に簡単です（0、2のランダムな値、MAX_INT、MIN_INTを整数引数に渡し、null可能の場合はnullなど）。次に、生成されたテストを実行し、各テストの結果を記録し、それらを手動でフィルター処理して無関係なものを削除し、合格するテストの許容可能な結果を​​承認し（それ以降は自動的に合格できるようにします）、失敗した無効なものとしてマークします。

クラスのタグ付け/コメント化/リファクタリングでこれを拡張して、ジェネレーターに追加のヒントを提供できます。メソッド呼び出しで発生する可能性のあるすべての例外をリストしたり、整数引数に有効な整数の範囲を狭めたりするタグがあります。テストを自分で作成する必要がある場合は、これらを省略形として見てください。

それで、あなたが見たいいくつかのコンポーネントがあります：

• ソースコード/関数署名/手動注釈を自動的に解析し、標準テストケースを作成するコンポーネント、または入力が完了するのを待つテストケースのアウトライン/署名。
• 自動テストビルダーへのヒントを表す、あらゆるレベルの粒度（メソッド/クラス/署名/ whileループなど）に移行する可能性のあるタグ/注釈/コメントの絶えず成長/変化する言語。理想的には、フレームワークまたはその中のチャンクを再コーディングすることなく、この言語で遊ぶことができるはずです
• 自動化されたテストランナー。新しい/古いテストを識別し、各テストの「許容できる」回答に対してテストを記録/テストできます。理想的には、このランナーはテスト実行、受け入れられた/拒否された結果、および各テストの現在の受け入れ可能な結果のデータベースを構築します。
• クラス名と名前のマップ->値を指定して、クラスを模倣するオブジェクトを生成し、関数呼び出し、アクセサ、パブリックデータスロットなどのカスタマイズ可能なデータを返す自動「オブジェクトフェイカー」

さまざまな言語およびプラットフォーム用のこの機能のチャンクをすでに含んでいるテストフレームワークがたくさんあります。自分でこの作業を開始し、社内でこの種のフレームワークを有機的に成長させることはかなり簡単ですが、おそらく既存の作業を複製する無限の長期プロジェクトでもあります。最初に利用可能なものを確認するためにかなりの時間を取ってから、飛び込むのに価値があるかどうかを判断することをお勧めします。

意味のあるサイズや複雑さのアプリケーションで使用する機会はまだありませんが、Javaアプリケーションの単体テストの生成を自動化するGoogleのCodePro AnalytiXなどのツールがあります。また、C ++単体テストの生成を可能にするように見える商用製品ParasoftのC ++ Testを見つけました。

これらのアプリケーションは、ヒューリスティックを使用してテストケースを生成しました。スケルトンを作成するために使用できる単一のフレームワークがあるかどうかはわかりませんが、探すことができるコンストラクトがあります。ループ、条件付きステートメント（ifブロック、switch/ caseステートメント）、および例外に焦点を当て、異なる実行パスを強制的に実行するテストケースを作成する傾向があります。

スケルトンやテンプレートを作成してテストの記述を高速化するのではなく、仕様や実装の分析を改善し、高品質のテストを作成することに重点を置きます。どのテストが最も価値を高めるかを早期に特定し、それらを記述して、後で穴を埋めることは、生産性と品質に大きな影響を与えます。

少し宣伝するために、FalconはプロジェクトでCodeProを試し、彼の経験についてちょっとした宣伝文句を書きました。

数年前、.NETプロジェクトのユニットテストを高速化するジェネレーターを作成しました。単体テストのない大規模なコードベースがあり、基本的なカバレッジを迅速に増やすことを目的としていました。ここに役立つかもしれないいくつかのメモがあります：

• 私のチャンスは、プロジェクトが開発されたコアフレームワークが標準操作とクラス命名を提供することでした。独自の記述を考えている場合は、このような標準構造が大いに役立ちます。
• data-driven testingコードベースで許可されている場合、使用は非常に役立ちます。テストフレームワークは、各ユニットテスト用のデータベーステーブルを作成してテストデータを保存し、そのテーブルの各行は個別のテストであり、追加のコードは不要でした（表現規則）。この時点から、実際のテストを簡単に自動作成するか、手動で入力できます。
• 結果の単体テストは単純でしたがsmoke test、少なくともs として機能しました。リスクの高い領域については、追加の手動テストが作成されました。

要約すると、一般的な解決策は実用的ではないことに同意します（可能な場合）。コードベースがテスト生成に適していて、テストフレームワークがその構造を利用できる場合、チャンスが増えると思います。

（補足として、Pexがありますが、.NET用です）