私は主に、win32 および .NET アプリケーションの自動テストに時間を費やしています。これらの時間の約 30% を記述に、70% を保守に費やしています。メンテナンス時間を短縮する方法を検討しており、すでにソフトウェアの主要コンポーネントのほとんどをカバーする再利用可能なテスト ライブラリに移行しています。さらに、ライブラリをキーワードベースのテストを使用できる状態にするための作業が進行中です。
テスト ライブラリの単体テストを検討していますが、時間をかける価値があるかどうか疑問に思っています。私はソフトウェアの単体テストの強力な支持者ですが、テスト コードの処理方法がわかりません。
自動化された Gui テスト ライブラリはユニット テストする必要があると思いますか? それともただの時間の無駄ですか？
まず第一に、単体テストをテストではなく「実行可能な仕様」と見なすことが非常に役立つことがわかりました。自分のコードで実行したいことを書き留めてから、それを実装します。単体テストを書くことで得られるメリットのほとんどは、単体テストが実装プロセスを促進し、私の思考に集中できることです。私のコードをテストするためにそれらが再利用可能であるという事実は、ほぼ偶然の一致です。
テストをテストすることは、問題を解決するのではなく、問題を動かす方法のように思えます。テストをテストする テストをテストするのは誰ですか? テストが実際に有用であることを確認するためにTDDが使用する「トリック」は、最初にテストを失敗させることです。ここでも使えるアイテムかもしれません。テストを書き、失敗することを確認してから、コードを修正します。
単体テストを単体テストする必要はないと思います。
ただし、カスタム アサーション、キーボード コントローラー、ボタン テスターなどを使用して独自のテスト ライブラリを作成した場合は、そうです。単体テストを作成して、すべてが意図したとおりに機能することを確認する必要があります。
たとえば、NUnit ライブラリは単体テスト済みです。
理論的には、これはソフトウェアであるため、単体テストを行う必要があります。特に、独自の単体テスト ライブラリを展開している場合は、その都度単体テストを行う必要があります。
ただし、プライマリ ソフトウェア システムの実際の単体テストは、単体テストが必要なほど大きくなってはいけません。それらが非常に複雑で単体テストが必要な場合は、ソフトウェアの深刻なリファクタリングと、単体テストを簡素化するための注意が必要です。
Who tests the tests を見てみるといいかもしれません。
簡単に言えば、コードがテストをテストし、テストがコードをテストするということです。
は？
原子時計
のテスト 類推から始めましょう。原子時計を持って旅行しているとします。時計が正しく調整されていることをどのように知ることができますか?1 つの方法は、近所の人に原子時計を持ってもらい (誰もが持っているため)、2 つを比較することです。両方が同じ時間を報告する場合、両方が正しいという高い信頼性があります。
それらが異なる場合、どちらかが間違っていることがわかります。
したがって、この状況で、「私の時計は正しい時刻を示していますか?」という唯一の質問がある場合、2 番目の時計をテストするために 3 番目の時計が必要であり、3 番目の時計をテストするには 4 番目の時計が本当に必要ですか? すべてではありません。スタックオーバーフローを回避！
IMPO: これは、どれだけの時間とどれだけの品質を確保したいかの間のトレードオフです。
Kent Beckの著書「テスト駆動開発：例による」には、単体テストフレームワークのテスト駆動開発の例が含まれているため、テストをテストすることは確かに可能です。
GUIや.NETを使用したことはありませんが、単体テストについてどのような懸念がありますか？
正しく機能している場合、ターゲットコードが正しくないと記述されるのではないかと心配ですか？これは可能性があると思いますが、これが起こっていればおそらくそれを検出できるでしょう。
または、そうでない場合でも、ターゲットコードが正しく機能していると記述される可能性があることを懸念していますか？あなたがそれについて心配しているなら、ミューテーションテストはあなたが求めているものかもしれません。ミューテーションテストでは、テスト対象のコードの一部を変更して、それらの変更によってテストが失敗するかどうかを確認します。そうでない場合は、コードが実行されていないか、そのコードの結果がテストされていません。
システムでミューテーションテストソフトウェアが利用できない場合は、ターゲットコードを自分で妨害し、単体テストが失敗するかどうかを確認することで、ミューテーションを手動で実行できます。
特定のアプリケーションに関連付けられていない単体テスト製品のスイートを構築している場合は、テストソフトウェアを実行して、期待される失敗と成功を確実に得ることができる簡単なアプリケーションを構築する必要があります。
ミューテーションテストの問題の1つは、プログラムが遭遇する可能性のあるすべての潜在的なシナリオをテストがカバーすることを保証しないことです。代わりに、ターゲットコードによって予測されるシナリオがすべてテストされることを保証するだけです。
はい、GUIテストライブラリをテストする必要があります。
たとえば、ライブラリが2次元配列に対してグリッドの内容を検証するためのCheckメソッドを提供している場合、それが意図したとおりに機能することを確認する必要があります。
そうしないと、グリッドが特定のデータを受信する必要があるビジネスプロセスをテストする、より複雑なテストケースが信頼できない可能性があります。Checkメソッドのエラーによってフォールスネガティブが発生した場合は、問題をすぐに見つけることができます。ただし、誤検知が発生する場合は、今後大きな頭痛の種になります。
CheckGridメソッドをテストするには：
CheckGridがエラーを正しく検出することをテストするには、ほとんどのフレームワークで次のdunitの例を変更できるはずです。
begin
//Populate TheGrid
try
CheckGrid(<incorrect values>, TheGrid);
LFlagTestFailure := False;
except
on E: ETestFailure do
LFlagTestFailure := True;
end;
Check(LFlagTestFailure, 'CheckGrid method did not detect errors in grid content');
end;
繰り返しになりますが、GUIテストライブラリをテストする必要があります。秘訣は-どうやって効果的にそうするのですか？
TDDプロセスでは、実際に実装する前に、まず新しい機能をテストする方法を理解することをお勧めします。その理由は、そうしないと、それがどのように機能するかを確認する方法について頭を悩ませることがよくあるからです。テストケースを既存の実装に後付けすることは非常に困難です。
あなたが言ったことが少し気になります...あなたは「（あなたの時間の）70％が（あなたのテスト）を維持するのにかかる」と言いました
これは私には少し間違っているように聞こえます。理想的には、テストは単純であり、インターフェイスまたはルールが変更された場合にのみ変更する必要があるためです。
誤解されているかもしれませんが、「プロダクション」コードを書かないという印象を受けました。それ以外の場合は、問題を減らすために、テストコードと本番コードを切り替えるサイクルをより細かく制御する必要があります。
いくつかの提案：
通常、次の経験則を使用します。
1）すべての製品コードには、単体テスト（製品コードのクラスと関数に密接に対応するように配置）と個別の機能テスト（ユーザーに表示される機能によって配置）の両方があります。
2）.NETコントロールなどのサードパーティコードやサードパーティライブラリのテストを作成しないでください。これの例外は、回避しているバグが含まれていることがわかっている場合です。これに対する回帰テスト（サードパーティのバグが消えると失敗します）は、サードパーティのライブラリへのアップグレードでバグが修正されたときに警告を発します。つまり、回避策を削除できます。
3）単体テストと機能テスト自体は直接テストされません-製品コードの前にテストを記述し、テストを実行して失敗を監視するTDD手順を使用することは別として。これを行わないと、常に合格するテストを誤って作成することがいかに簡単であるかに驚かれることでしょう。理想的には、製品コードを一度に1ステップずつ実装し、変更のたびにテストを実行して、テスト内のすべてのアサーションが失敗することを確認し、実装して合格を開始します。次に、次のアサーションが失敗するのがわかります。このようにして、テストはテストされますが、製品コードが記述されている間だけです。
4）単体テストまたは機能テストからコードを除外する場合（多くのテストで使用されるテストライブラリを作成する場合）、これらすべてを単体テストします。
これは私たちに非常に役立ちました。私たちは常にこれらのルールを100％守ってきたようで、私たちの取り決めには非常に満足しています。
ライブラリを単体テストできる/すべきではない理由は本当にありません。一部の部分は適切に単体テストするのが難しすぎるかもしれませんが、ほとんどの部分はおそらく特に問題なく単体テストできます。
この種のコードの単体テストは、信頼性と再利用性の両方が期待されるため、実際にはおそらく特に有益です。
テストはコードをテストし、コードはテストをテストします。同じ意図を 2 つの異なる方法 (テストで 1 回、コードで 1 回) で言う場合、両方が間違っている可能性は非常に低くなります (要件が既に間違っていない限り)。これは、会計士が使用する複式簿記と比較することができます。http://butunclebob.com/ArticleS.UncleBob.TheSensitivityProblemを参照してください。
最近、 http://blog.objectmentor.com/articles/2009/01/31/quality-doesnt-matter-that-much-jeff-and-joelのコメントで、この同じ問題についての議論がありました。
あなたの質問については、GUI テスト ライブラリをテストする必要があります... 私の理解が正しければ、あなたは独自のテスト ライブラリを作成しており、テスト ライブラリをテストする必要があるかどうかを知りたいと考えています。はい。ライブラリに依存してテストを正しく報告できるようにするには、ライブラリが偽陽性または偽陰性を報告しないことを確認するテストが必要です。テストが単体テスト、統合テスト、受け入れテストのいずれであるかに関係なく、少なくともいくつかのテストが必要です。
通常、コードを書いてから単体テストを書くのは遅すぎます。単体テストでは、コードをさらに分離する必要があります。そうしないと、小さな単位 (クラスまたは密接に関連するクラスのグループ) を分離してテストすることができないからです。
コードが既に作成されている場合、通常は統合テストと受け入れテストのみを追加できます。それらはシステム全体が実行されている状態で実行されるため、機能が正しく動作することを確認できますが、すべてのコーナー ケースと実行パスをカバーすることは単体テストよりも困難です。
個人的には、自動化ライブラリの単体テストは行いません。すべてのチェックポイントが機能することを確認するために、修正したバージョンのベースラインに対してそれらを実行します。ここでの原則は、私の自動化は主に回帰テスト用であるということです。たとえば、現在の実行の結果が期待される結果と同じであることです (通常、これは最後の実行の結果に相当します)。適切に変更された期待される結果のセットに対してテストを実行すると、すべてのテストが失敗するはずです。そうでない場合は、テスト スイートにバグがあります。これはミューテーション テストから借用した概念であり、GUI 自動化スイートのチェックに適しています。
あなたの質問から、自動化テストを実行するためのキーワード駆動型フレームワークを構築していることがわかります。この場合、共通機能と GUI ユーティリティ機能についてホワイト ボックス テストを行うことを常にお勧めします。ライブラリ内の各 GUI テスト機能の単体テストに関心があるので、ぜひ行ってください。テストは常に良好です。時間の無駄ではありません。あなたのフレームワークに「付加価値」を与えるものだと思います。
テストコードの処理についても言及しましたが、テストアプローチを意味する場合は、同様の作業を実行するさまざまな機能/モジュールをグループ化してください。たとえば、GUI 要素の検証 (存在)、GUI 要素の入力、GUI 要素の読み取りなどです。さまざまな要素タイプをグループ化し、グループごとにタイプ ユニット テスト アプローチを実行します。テストを追跡する方が簡単です。乾杯！
ミューテーションテスト フレームワークを探索することもできます (Java を使用している場合は、PIT Mutation Testingを参照してください)。単体テストの品質を評価するもう 1 つの方法は、SonarQubeなどのツールによって提供されるレポートを確認することです。レポートには、さまざまなカバレッジ メトリックが含まれます。