プログラムのホワイト ボックス テストを容易にするためのプログラミングの設計パターンがあるかどうか疑問に思っています。単体テストについて話しているのではなく、ホワイトボックスベースの機能テスト、システムテスト、または境界テストなどのより高いレベルのテストです。
例えば：
GUI ベースのプログラムの場合、隠しスイッチを予約して、GUI の代わりにテキスト ファイルから入力を読み取ることができます。
一部の HTTP ベースの C/S アプリケーションでは、パッケージ送信中に gzip オプションを無効にするパラメーターを提供します。これにより、Fiddler を使用して HTTP パッケージを変更しやすくなります。
他のパターンや原則はありますか?
私はあなたの質問を完全に理解しているかどうかわかりませんが、
言い換えれば、どのシナリオで何をテストしているのか (システム全体、このモジュール/クラス/関数/その他) を知る必要があります (無効な入力を与えたとき、ユーザーがこれを行ったとき、それからあれを行ったとき、など) そして、そのテストが考慮されるほど重要である理由 (一般的な用途であり、境界条件をテストするなど)。
ウィキペディアのソフトウェア テストに関する記事の「テスト方法」と「テスト レベル」のセクションは、必要なテストの種類を判断するのに役立つと思います。
アプリケーション コードと同じレベルのエンジニアリング品質でテストを維持する必要があります。その点で、問題を解決するのに役立つすべてのパターンを適用してください。
個人的には、テストのためだけに秘密の突く穴を作るのは、いくつかの理由から悪い考えだと思います。ほんの数例を挙げると：
微妙な方法で想定される相互作用を確実に再現できない可能性があります。「テスト ショートカット」は、通常のユーザーとまったく同じものをトリガーしない場合があります。コードとテストに変更をコミットするたびに、バイパスしているもの (およびその影響) を 100% 確実に把握する必要があります。
テストには優れた設計が必要です。何かをテストするのが面倒なら、設計に疑問を抱くことを考えたことはありますか? 何かをテストするということは、スクリプト化された方法でそれを使用することです。製品を使用することは苦痛であってはなりません。(ただし、テストのスクリプト作成は、一部の環境では苦痛になる場合があります。はい、承知しています。) これは、特に単体テストに当てはまります。
不注意なプログラマーが、テスト ショートカットを実際の正当な通常のユース ケースに変えるのは良い考えだと考える可能性は常にあります。特に、コードの一部が残りのコードと同じように徹底的に考え抜かれていると想定している場合 (通常はそうではありません)、これにはすべてが当てはまります。
ホワイトボックス テストで私が見つけた最も有用な領域の 1 つは、マルチスレッドの問題のコーナー ケースです。ストレステストと祈りしかないか、遅延とセマフォを追加してテストをカバーしようとして、物事が発生するようにします。
しかし、テストケースのパターンがあるとは思えません。パターンは、非常に正確に定義された状況でのみ役立ちます。Gamma によるオリジナルのパターン ブックのコーディングにどれだけ近いかを覚えておいてください。
他のすべては単なるストーリーテリングであり、経験を共有するために重要ですが、パターンではありません.