テストのテスト方法は？

コードをテストして、コードをより正確にします（実際、不正確になる可能性は低くなります）。ただし、テストはコードでもあり、エラーが含まれることもあります。また、テストにバグがある場合は、コードが改善されることはほとんどありません。

テストで考えられる3種類のエラーを考えることができます。

1. プログラマーが目前のタスクを誤解し、テストが実行すべきだと思ったとおりにテストを実行する場合の論理エラー。これは誤りです。

2. 基礎となるテストフレームワークのエラー（例えば、漏れやすいモックの抽象化）。

3. テストのバグ：テストは、プログラマーが考えていることとは少し異なっています。

タイプ（1）のエラーを防ぐことは不可能と思われます（プログラマーが...賢くならない限り）。ただし、（2）および（3）は扱いやすい場合があります。これらのタイプのエラーにどのように対処しますか？それらを避けるための特別な戦略はありますか？たとえば、テスト作成者の前提条件のみをチェックする特別な「空の」テストを作成しますか？また、壊れたテストケースのデバッグにどのように取り組みますか？

テストはすでにテストされています。テストではコードと期待値の違いのみが検出されるため、テストはバグから保護されています。問題がある場合、エラーが発生します。エラーはコード内にあるか、テストで同じ確率で発生する可能性があります。

1. コードとテストの両方に同じバグを追加できないようにするテクニックがいくつかあります。

   1. クライアントは、実装者とは異なる人でなければなりません。
   2. 最初にテストを作成し、次にコードを作成します（テスト駆動開発など）。

2. 基盤となるプラットフォームをテストする必要はありません。テストは、ユーザーが作成したコードを実行するだけでなく、プラットフォームからもコードを実行します。テストプラットフォームでバグをキャッチする必要はありませんが、プラットフォームのバグを常に隠すコードやテストを書くのは非常に困難です。つまり、テスト/コードとプラットフォームで、作成するテストごとに確率が低下します。これを実行しようとしても、非常に難しいタスクになります。

3. テストにバグがある場合もありますが、テストは開発されたコードによってテストされるため、通常は簡単に発見されます。コードとテストの間には、自己執行フィードバックがあります。どちらも、インターフェイスの特定の呼び出しがどのように動作するかについて予測を行います。応答が異なる場合、コードにバグがある必要はありません。テストにもバグがある可能性があります。

個々のテストをできるだけ小さく（短く）してみてください。

これにより、そもそもバグが作成される可能性が低くなります。作成したとしても、簡単に見つけることができます。単体テストは小規模で具体的で、障害や偏差に対する許容度が低いと想定されています。

結局のところ、それはおそらく経験の問題でしょう。より多くのテストを作成すればするほど、より上手になればなるほど、安っぽいテストを作成する必要が少なくなります。

1つの方法は、テストするコードの前にテストを記述し、正しい理由で最初にテストが失敗するようにすることです。TDDを使用する場合は、少なくともこのレベルのテストをテストする必要があります。

テストスイートの品質をテストするより包括的な方法は、突然変異テストを使用することです。

＃1および＃3の場合：ユニットテストにはロジックを含めないでください。そうする場合、おそらくユニットテストで複数のことをテストしていることになります。単体テストのベストプラクティスの1つは、単体テストごとにテストを1つだけにすることです。

ユニットテストの作成方法の詳細については、Roy Osheroveによるこのビデオをご覧ください。

＃1に関して言えば、この側面については、コードレビューとペア設定することをお勧めします。前提条件を立てたり、物事を間違えたりするのは簡単ですが、テストが何をしているのか、ポイントは何かを説明する必要がある場合、間違ったターゲットに照準を合わせている場合は拾いやすくなります。

単体テストの試行を停止するポイントが必要です。いつ線を引くか知っている必要があります。テストケースをテストするためにテストケースを作成する必要がありますか？テストテストケースに書き込まれた新しいテストケースについてはどうですか？それらをどのようにテストしますか？

if (0 > printf("Hello, world\n")) {
  printf("Printing \"Hello, world\" failed\n");
}

編集：コメントで提案された説明で更新されました。

ねえ。
アプリケーションが必要です：

• あなたの製品
• その製品のテスト。

製品に対してテストを実行しているとき、実際にはテスト自体に興味がなく、製品とテストの間の相互作用に興味があります。テストが失敗しても、アプリケーションにバグがあるとは言いません。製品とテストの相互作用は成功しなかったと言っています。今、何が悪いのかを判断するのはあなたの仕事です。次のいずれかです。

• アプリケーションは期待どおりに動作していません（この期待はテストで表されています）
• アプリケーションが正しく動作している、あなたはちょうどあなたのテストでこの動作を正しく文書化していない

私にとって、テストの失敗は単純なフィードバックではなく、あれこれが間違っているということです。これは矛盾があることを示す指標であり、両方を調べて、問題が発生したかどうかを確認する必要があります。最後に、アプリケーションが正しいことを確認する責任があります。テストは、チェックする価値のある領域を強調するための単なるツールです。

テストでは、アプリケーションの一部のみをチェックしています。アプリケーションをテストし、テストをテストします。

テストは、バグを隠すほど「スマート」であってはなりません。

記述しているコードは、一連の仕様を実装しています。（Xの場合はY、Zの場合はQ、など）。テストは、ZがQの場合を除き、Xが実際にYであると判断することです。これは、テストでXを設定し、Yを検証することだけを意味します。

しかし、それはすべてのケースをカバーしているわけではなく、おそらくあなたは言っているでしょう、そしてあなたは正しいでしょう。しかし、テストを「スマート」にして、XがZではなくYだけでなければならないことを十分に理解している場合、基本的にはテストでビジネスロジックを再実装しています。これは、以下でもう少し詳しく説明する理由から問題があります。最初のテストを「賢く」することでコードカバレッジを改善するべきではなく、代わりにXとZを設定してQを検証する2番目のダムテストを追加する必要があります。ハッピーパスとも呼ばれます）、エッジケースを個別のテストとしてカバーするものです。

これにはいくつかの理由がありますが、何よりもまず、失敗したテストがビジネスロジックのバグによるものか、テストのバグによるものかをどのように判断するのですか？明らかに、答えは、テストが可能な限り単純であれば、バグを抱えている可能性は非常に低いということです。 テストにテストが必要だと思うなら、あなたは間違ってテストしています。

その他の理由としては、要件が変更された場合、努力を複製しているだけです（既に述べたように、単一のテストですべての可能性を発揮するのに十分なスマートテストを書くことは、基本的にテストしようとしているビジネスロジックを複製することです）その後、テストは新しい要件を反映するように簡単に変更でき、テストは一種のドキュメントとして機能します（テスト対象のユニットの仕様が何であるかを言う正式な方法です）。

TL：DR：テストにテストが必要な場合は、間違っています。 ダムテストを書いてください。

答えではありません（コメントする権限はありません）が、テストケースを開発する他の理由を忘れてしまったのではないかと考えていました
。自動化されたテストスイートは、統合の前に、問題を早期に発見するのに役立ちます。要件への変更は比較的簡単にテストできます。変更が新しいものになり、合格した古いテストケースの変更されたバージョンになる可能性があり、古いケースが失敗を拾い続けるためです。

簡単な答え：製品コードはテストをテストします。

これを経済学で使用されるクレジット/デビットモデルと比較してください。仕組みは非常に単純です-クレジットが借方と異なる場合、何か間違っています。

同じことがユニットテストにも当てはまります-テストが失敗した場合、何かが間違っていることを示します。実動コードである場合もありますが、テストコードである場合もあります。重要な場合、この最後の部分。

タイプ（1）のバグは単体テストでは検出できないことに注意してください。このタイプのバグを回避するには、他のツールが必要です。