タグ付けされた質問 「unit-testing」

コードをテストして、コードをより正確にします（実際、不正確になる可能性は低くなります）。ただし、テストはコードでもあり、エラーが含まれることもあります。また、テストにバグがある場合は、コードが改善されることはほとんどありません。 テストで考えられる3種類のエラーを考えることができます。 プログラマーが目前のタスクを誤解し、テストが実行すべきだと思ったとおりにテストを実行する場合の論理エラー。これは誤りです。 基礎となるテストフレームワークのエラー（例えば、漏れやすいモックの抽象化）。 テストのバグ：テストは、プログラマーが考えていることとは少し異なっています。 タイプ（1）のエラーを防ぐことは不可能と思われます（プログラマーが...賢くならない限り）。ただし、（2）および（3）は扱いやすい場合があります。これらのタイプのエラーにどのように対処しますか？それらを避けるための特別な戦略はありますか？たとえば、テスト作成者の前提条件のみをチェックする特別な「空の」テストを作成しますか？また、壊れたテストケースのデバッグにどのように取り組みますか？

53 unit-testing  tdd  debugging 

通常、コピーアンドペーストおよびその他のあらゆる悪い慣行を使用して、単体テストを一緒にスローします。通常、単体テストは非常に見苦しく、「コードのにおい」に満ちていますが、これは本当に重要ですか？「本当の」コードが「良い」ものである限り、それは重要なことです。さらに、ユニットテストでは通常、スタブ機能などのさまざまな「臭いハック」が必要です。 不十分に設計された（「臭い」）単体テストについて、どの程度心配する必要がありますか？

52 unit-testing  code-quality  code-smell 

アサートと単体テストの両方は、コードベースのドキュメントとして、またバグを発見する手段として機能します。主な違いは、アサートが健全性チェックとして機能し、実際の入力を確認するのに対して、ユニットテストは特定のシミュレートされた入力で実行され、明確に定義された単一の「正しい答え」に対するテストです。正当性を検証する主な手段として、アサーションと単体テストを使用する相対的なメリットは何ですか？どちらをもっと強調すべきだと思いますか？

51 testing  unit-testing  assertions 

65.000.000.000テストのスイートを実行する方法について尋ねられたので、このような膨大なテストを含むプロジェクトがあるのは普通かと思います。 この特性を持つプロジェクトで働いたことはありますか？

50 testing  unit-testing  continuous-integration 

私は成長中のプログラマーで、GitHubに保存しているライブラリの単体テストを最終的に実践しています。 レポジトリにテストスイートを含めることができたのですが、他のプロジェクトを見てみると、テストを含めるのは失敗したように思えます。 これは悪い形と見なされますか？ユーザーは作業コードにのみ興味があり、とにかく自分のフレームワークでテストするという考えはありますか？

50 version-control  unit-testing 

このサイトには、自動テストから得られる利点に関する多くの情報を提供する多くの質問があります。しかし、私はコインの反対側を表すものを見ませんでした：欠点は何ですか？人生のすべてはトレードオフであり、特効薬はありませんので、自動テストを行わない正当な理由が必ずあるはずです。彼らは何ですか？ ここに私が思いついたいくつかがあります： 特定の機能に対して初期開発者の時間がさらに必要です チームメンバーの高いスキルレベルが必要 ツールのニーズを増やす（テストランナー、フレームワークなど） 失敗したテストが発生した場合に必要な複雑な分析-このテストは私の変更により廃止されたのですか、それとも間違いを犯したと言っているのですか？ 編集 私は自動化されたテストの巨大な支持者であると言っておくべきであり、私はそれをすることを納得させるつもりはありません。欠点が何なのかを理解したいと思っているので、会社に行って主張するとき、次の想像上の銀の弾丸を投げているようには見えません。 また、上記の私の例に異議を唱える人を探していないことを明確にしています。私は、いくつかの不利な点（すべてにトレードオフがある）がなければならないことを真実と考えており、それらが何であるかを理解したいと思います。

49 testing  unit-testing  tdd  automation  test-automation 

仕事中の私のチームはスクラムに移行しており、他のチームは単体テストとユーザー受け入れテストを使用してテスト駆動開発を始めています。私はUATが好きですが、テスト駆動開発または一般にテスト駆動開発の単体テストで販売されていません。 テストを書くことは余分な作業であり、実際のコードを書くときに人々に松葉杖を与えるようで、あまり効果的ではないかもしれません。 ユニットテストがどのように機能し、どのように記述するかを理解していますが、それは本当に良いアイデアであり、努力と時間の価値があると主張することができますか？ また、スクラムにとってTDDが特に優れているものはありますか？

48 unit-testing  scrum  tdd 

私のプログラムの統合テストがすでにあり、それらすべてが合格した場合、それはうまくいくと感じています。次に、単体テストを作成/追加する理由は何ですか？とにかく統合テストを書く必要があるので、統合テストでカバーされていない部品の単体テストのみを書きたいと思います。 統合テストよりも単体テストの利点を知っているのは 小さく、したがって高速に実行できます（ただし、テストに新しいユニットを追加すると、統合テストで既にテストされているため、テストスーツ全体が大きくなり、実行時間が長くなります） 1つのことしかテストしないため、バグを見つけやすくなります（ただし、統合テストが失敗した場合は、個々のパーツを検証するために単体テストの書き込みを開始できます） 統合テストで検出されない可能性のあるバグを見つけます。たとえば、マスキング/オフセットのバグ。（ただし、統合がすべてのパスをテストする場合、プログラムは隠れたバグが存在する場合でも動作します。したがって、将来の統合テストを中断したり、パフォーマンスの問題を引き起こさない限り、これらのバグを見つける/修正することは優先度が高くありません） そして、私たちは常により少ないコードを書きたいのですが、単体テストを書くにはもっと多くのコードが必要です（主にモックオブジェクトをセットアップします）。単体テストと統合テストのいくつかの違いは、単体テストではモックオブジェクトを使用し、統合テストでは実際のオブジェクトを使用することです。重複が多く、コードの動作を変更するためのオーバーヘッドが追加されるため、テストでもコードの複製は好きではありません（リファクタリングツールは常にすべての作業を行うことはできません）。

47 testing  unit-testing  tdd  integration-tests 

この質問は、単体テストフレームワークに関するものではありません。 この質問は、単体テストの作成に関するものではありません。 この質問は約あるところ書かれたUTのコードを配置する方法と、/とき/コンパイルし、それを実行する場所。 レガシーコードを効果的に使用するにあたって、Michael Feathersは次のように主張しています。 優れた単体テスト...高速で実行 そしてそれ 実行に1/10秒かかる単体テストは、低速の単体テストです。 これらの定義は理にかなっていると思います。私はまた、ユニットテストのセットと、より長い時間がかかるコードテストのセットを別々に保持する必要があることを示唆していると思いますが、それが（非常に）高速に実行される場合、ユニットテストと呼ばれるものだけに支払う代償だと思います。 明らかに問題 ++ Cでは、「実行」へのあなたのユニットテスト（複数可）、あなたがする必要があります。 コードを編集します（使用している「サイクル」に応じて、本番またはユニットテスト） コンパイル リンク 単体テスト実行可能ファイルの開始（s） 編集（奇妙な近い投票の後）：詳細に入る前に、ここでポイントを要約してみます： （テスト）コードの編集とテストコードの実行の両方が効率的になるように、C ++ユニットテストコードを効果的に編成するにはどうすればよいですか？ 最初の問題は、その後、決定することですどこようにユニットテストコードを配置します： 関連する製品コードと組み合わせて編集および表示するのは「自然」です。 現在変更しているユニットのコンパイルサイクルを開始するのは簡単です。 次に、関連する2番目の問題は、フィードバックが瞬時に行われるようにコンパイルするものです。 極端なオプション： 各Unit-Test-Test-Unitは個別のcppファイルに存在し、このcppファイルは（テストするソースコードのユニットファイルと共に）個別にコンパイルおよびリンクされ、単一の実行可能ファイルにリンクされます。 （+）これにより、単一のテストユニットの起動（コンパイル+リンク！）時間を最小限に抑えることができます。 （+）テストは1つのユニットのみをテストするため、超高速で実行されます。 （-）スイート全体を実行するには、膨大な数のプロセスを開始する必要があります。管理することが問題になる場合があります。 （-）プロセス開始のオーバーヘッドが見えるようになる 反対側は、テストごとに1つのcppファイルを持っていますが、すべてのテストcppファイルは（テストするコードとともに）1つの実行可能ファイルにリンクされています（モジュールごと/プロジェクトごと/選択を選択してください）。 （+）変更されたコードのみがコンパイルされるため、コンパイル時間は問題ありません。 （+）実行するexeは1つしかないため、スイート全体の実行は簡単です。 （-）任意のオブジェクトを再コンパイルすると再リンクがトリガーされるため、スイートはリンクするのに時間がかかります。 （-）（？）スーツの実行には時間がかかりますが、すべてのユニットテストが高速であれば、時間は問題ないはずです。 それでは、実際のC ++ 単体テストはどのように処理されますか？夜間/毎時だけ実行する場合、2番目の部分は実際には重要ではありませんが、最初の部分、つまりUTコードを本番コードに「結合」する方法です。フォーカスは常に重要だと思います。（そして、開発者がUTコードに焦点を合わせている場合、彼らはそれを実行したいと思うので、パート2に戻ります。） 現実世界の物語と経験に感謝します！ ノート： この質問は、意図しないプラットフォームとメイク/プロジェクトシステムを意図的に残します。 質問タグ付きUT＆C ++は開始するのに最適な場所ですが、残念ながらあまりにも多くの質問、特に回答が詳細や特定のフレームワークに集中しすぎています。 少し前に、ブーストユニットテストの構造に関する同様の質問に答えました。この構造は、「実際の」高速な単体テストには欠けていることがわかりました。そして、私は他の質問が狭すぎると思うので、この新しい質問です。

47 c++  unit-testing  tdd  projects-and-solutions 

私はphpunitのドキュメントを調べてきましたが、次の引用に出くわしました： いつでもテストを作成できます。ただし、想像できるテストのほんの一部だけが実際に有用であることがすぐにわかります。あなたがしたいのは、あなたがそれらがうまくいくと思っていても失敗するテスト、またはあなたはそれらが失敗すると思っても成功するテストを書くことです。それを考える別の方法は、費用/利益の観点からです。情報を返してくれるテストを書きたい。-エーリッヒガンマ 不思議に思いました。コスト/ベネフィットについての引用で述べられていることを別にして、ユニットテストが他のテストよりも有用である理由をどのように判断しますか 単体テストを作成するコードの部分をどのように決定しますか？それらの引用の別のものも言ったので、私はそれを求めています： それで、それがテストに関するものでない場合、それは何についてですか？それはあなたがそれをしようとするために半コックから逃げる前にあなたがしようとしていることを理解することです。動作の小さな側面を簡潔で明確で実行可能な形式で記述する仕様を作成します。とても簡単です。テストを書くということですか？いいえ。コードが何をする必要があるかについての仕様を記述することを意味します。コードの動作を事前に指定することを意味します。しかし、そう遠くはない。実際、コードを記述する直前が最適です。なぜなら、その時点までに必要なだけの情報が手元にあるからです。よくできたTDDと同様に、少しずつ作業を進めます。一度に1つの動作の小さな側面を指定し、それを実装します。すべてが動作を指定することであり、テストを作成することではないことに気付いたら、あなたの視点が変わります。突然、プロダクションクラスごとにテストクラスを持つという考えはとんでもなく制限されます。そして、各メソッドを独自のテストメソッド（1対1の関係）でテストするという考えは笑えるでしょう。-デイブ・アステルス その重要なセクションは * そして、各メソッドを（1-1の関係で）独自のテストメソッドでテストするという考えは、笑えるでしょう。* 各メソッドのテストを作成することが「笑える」場合、どのように/いつテストを書くかを選択しますか？

47 unit-testing 

どのようにしてユニットマネージャーにあなたをマネージャーに納得させましたか？ 「使用」とは、ソース管理への開発、チェックイン、および長期にわたる単体テストの維持などを許可することを意味します。 一般的な管理の反対意見は次のとおりです。 顧客は単体テストの費用を支払わなかった このプロジェクトでは、単体テストの時間が許可されていません 技術的負債？どのような技術的負債ですか？ 他の異議を知っていますか？あなたの答えは何でしたか？ 前もって感謝します！

46 project-management  management  unit-testing  tdd 

組み込みシステム用に記述されたユニットテストコードのベストプラクティス戦略を探しています。組み込みシステムとは、デバイスドライバー、ISRハンドラーなどのコード、つまり金属に非常に近いものを意味します。 ICEを使用してハードウェアでテストしないと、ほとんどのユニットテストは不可能です。組み込みユニットは、機械式スイッチ、ステッピングモーター、電球などの他の刺激にも接続する必要がある場合があります。これは通常、手動で行われます。自動化は優れていますが、達成するのは難しく、費用がかかります。 更新 組み込みプロジェクトのテストで非常に成功していると思われるCテストフレームワークに出会いました。ハードウェアをモックするというアイデアを使用します。チェックアウトユニティ、CMockを、そしておそらくceedlingが。 2016年7月6日更新 出くわしたcmocka -より積極的に取り組んでいるように見えます。

45 unit-testing  embedded-systems 

私たちの同僚は、ユニットテストの作成を、実際に設計を改良し、リファクタリングするのに役立つものとして推進していますが、その方法はわかりません。CSVファイルを読み込んで解析する場合、ユニットテスト（フィールドの値の検証）は設計の検証にどのように役立ちますか？彼は結合やモジュール性などに言及しましたが、私にはあまり意味がありません-しかし、私は理論的な背景があまりありません。 それはあなたが重複とマークした質問と同じではありません。私は、「それが役立つ」という理論だけでなく、これがどのように役立つかの実際の例に興味があります。私は以下の回答とコメントが好きですが、もっと学びたいです。

43 design  unit-testing  object-oriented-design 

私の現在のプロジェクトは、簡潔に「制約のあるランダムなイベント」の作成に関係しています。私は基本的に検査のスケジュールを生成しています。それらのいくつかは、厳密なスケジュールの制約に基づいています。金曜日の午前10:00に週に1回検査を行います。他の検査は「ランダム」です。「検査は週に3回行う必要がある」、「検査は午前9時から午後9時までの間に行う必要がある」、「同じ8時間内に2つの検査を行うべきではない」などの基本的な構成可能な要件がありますが、特定の検査セットに対して設定された制約の範囲内で、結果の日付と時刻は予測できません。 ユニットテストとTDD、IMOは、このシステムで大きな価値があります。これは、要件の完全なセットがまだ不完全でありながら、段階的にビルドするために使用できるためです。現在、私が必要だとは知らない。厳密なスケジュールは、TDDにとって欠かせないものでした。ただし、システムのランダムな部分のテストを作成するときに、テスト対象を実際に定義するのは難しいと感じています。スケジューラによって生成されるすべての時間は制約内に収まる必要があると断言できますが、実際の時間を非常に「ランダム」にせずにこのようなすべてのテストに合格するアルゴリズムを実装できます。実際、それはまさに起こったことです。時刻は、正確には予測できませんが、許容される日付/時刻範囲の小さなサブセットに分類される問題を発見しました。アルゴリズムは、私が合理的に行うことができると思うすべてのアサーションに合格し、そのような状況で失敗する自動テストを設計することはできませんでしたが、「よりランダムな」結果が与えられると合格します。既存のテストを再構築して何度も繰り返すことで問題が解決したことを実証し、生成された時間が完全に許容範囲内に収まったことを視覚的に確認する必要がありました。 非決定論的な動作を期待するテストを設計するためのヒントはありますか？ すべての提案に感謝します。主な意見は、決定論的で、再現性があり、主張可能な結果を​​得るために、決定論的テストが必要だということです。理にかなっています。 制約プロセス（任意の長いバイト配列が最小と最大の間で長くなるプロセス）の候補アルゴリズムを含む一連の「サンドボックス」テストを作成しました。次に、そのコードをFORループで実行し、アルゴリズムにいくつかの既知のバイト配列（開始時に1から10,000,000の値）を与え、アルゴリズムにそれぞれ1009から7919の間の値に制約させます（素数を使用して、アルゴリズムは、入力範囲と出力範囲の間で偶然のGCFを通過しません）。結果の制約値がカウントされ、ヒストグラムが作成されます。「パス」するには、すべての入力をヒストグラム内に反映する必要があり（「失わない」ようにするための健全性）、ヒストグラム内の2つのバケットの差は2より大きくすることはできません（実際には<= 1でなければなりません） 、しばらくお待ちください）。勝ったアルゴリズムがあれば、それをカットして実動コードに直接貼り付け、永続的なテストを実施して回帰することができます。 コードは次のとおりです。 private void TestConstraintAlgorithm(int min, int max, Func<byte[], long, long, long> constraintAlgorithm) { var histogram = new int[max-min+1]; for (int i = 1; i <= 10000000; i++) { //This is the stand-in for the PRNG; produces a known byte array var buffer = …

41 algorithms  unit-testing  random 

赤、緑、リファクタリングのサイクルを実行するときは、常にテストに合格するための最小限のコードを記述する必要があります。これは私がTDDについて教えられてきた方法であり、ほとんどすべての本がプロセスを説明する方法です。 しかし、ロギングはどうですか？ 正直なところ、実際に複雑なことが起こっていない限り、アプリケーションでのログ記録はほとんど使用していませんが、適切なログ記録の重要性に関する多くの投稿を見てきました。 そのため、例外をログに記録する以外に、適切にテストされたアプリケーション（ユニット/統合/受け入れテスト）にログを記録することの本当の重要性を正当化できませんでした。 だから私の質問は： TDDを実行している場合、ログを記録する必要がありますか？テストに失敗しても、アプリケーションのどこが悪いのかわかりませんか？ 各クラスの各メソッドにロギングプロセスのテストを追加する必要がありますか？ たとえば、実稼働環境でいくつかのログレベルが無効になっている場合、テストと環境の間に依存関係が生じませんか？ 人々はログがデバッグを容易にする方法について話しますが、TDDの主な利点の1つは、テストの失敗によって何が間違っているかを常に知っていることです。 私がそこに欠けているものはありますか？

40 design  object-oriented  unit-testing  tdd  logging