タグ付けされた質問 「test-coverage」

私は大学を卒業したばかりで、来週どこかで大学を始めています。単体テストを見てきましたが、あまり使用しませんでした。誰もがそれらについて話すので、私はいくつかのことをすべきだと思いました。 問題は、何をテストすべきかわからないことです。一般的なケースをテストする必要がありますか？エッジケース？機能が適切にカバーされていることを知るにはどうすればよいですか？ 特定のケースで機能が機能することをテストで証明することはできますが、機能が機能することを証明することはまったく役に立たないという恐ろしい気持ちが常にあります。

122 unit-testing  testing  test-coverage 

プログラムを通るすべてのパスがテストされる場合、それはすべてのバグを見つけることを保証しますか？ そうでない場合は、なぜですか？プログラムフローのあらゆる可能な組み合わせを通過し、問題が存在する場合はそれを見つけられないのはどうしてですか。 「すべてのバグ」が見つかる可能性があることをお勧めしますが、おそらくパスカバレッジが実用的ではないため（組み合わせであるため）、これまで経験したことがないためでしょうか。 注：この記事では、私が考えているカバレッジタイプの概要を簡単に説明します。

64 testing  test-coverage 

私は、既存のJavaプロジェクトのコードカバレッジを増やすように依頼されました。 コードカバレッジツール（EclEmma）が、どこからも呼び出されないメソッドを強調していることに気付きました。 私の最初の反応は、これらのメソッドの単体テストを書くことではなく、ラインマネージャー/チームにそれらを強調し、これらの機能がそもそもなぜあるのかを尋ねることです。 最善のアプローチは何でしょうか？それらの単体テストを作成するか、それらがなぜ存在するのか疑問に思いますか？

59 java  unit-testing  test-coverage 

ユニットテストの下でレガシーアプリケーションを取得することを任されています。アプリケーションに関する最初の背景：これらの主要な問題を伴う600k LOC Java RCPコードベースです。 大規模なコードの複製 カプセル化なし、ほとんどのプライベートデータは外部からアクセスできます。ビジネスデータの一部はシングルトンにもなっているため、外部からだけでなくどこからでも変更できます。 抽象化なし（たとえば、ビジネスモデルなし、ビジネスデータはObject []およびdouble [] []に格納されます）。したがって、OOはありません。 優れた回帰テストスイートがあり、効率的なQAチームがバグのテストと発見を行っています。マイケル・フェザーズなどの古典的な本からテストする方法を知っていますが、それは遅すぎます。実用的なリグレッションテストシステムがあるので、ユニットテストを作成できるようにシステムを積極的にリファクタリングすることを恐れていません。 迅速にカバレッジを得るために、どのように問題を攻撃し始める必要がありますか？そうすれば、経営陣に進捗を示すことができます（実際には、JUnitテストのセーフティネットから収益を上げることができます）？AgitarOneなどの回帰テストスイートを生成するツールを使用したくないのは、これらのテストは何かが正しいかどうかをテストしないためです。

21 object-oriented  refactoring  test-coverage  junit 

80％のテストカバレッジ（すべてのテストに合格）を持つコードがある場合、テストカバレッジのないコードよりも品質が高いと言ってもいいでしょうか？ それとも、それがより保守可能であると言うのは公平ですか？

20 code-quality  test-coverage 

Java 8が登場して以来、現在のJava用ツールによる条件付きコードカバレッジの測定は時代遅れではないのかと思っています。Javaの8のではOptionalとStream私たちはしばしば、それが簡単にすべての可能な実行パスをテストすることなく、非常に高い条件カバレッジを取得することができますコード分岐/ループを回避することができます。古いJavaコードとJava 8コードを比較してみましょう。 Java 8より前： public String getName(User user) { if (user != null) { if (user.getName() != null) { return user.getName(); } } return "unknown"; } 上記のメソッドには3つの実行パスがあります。条件付きカバレッジを100％取得するには、3つの単体テストを作成する必要があります。 Java 8： public String getName(User user) { return Optional.ofNullable(user) .map(User::getName) .orElse("unknown"); } この場合、ブランチは非表示になり、100％のカバレッジを得るために必要なテストは1つだけで、テストするケースは関係ありません。カバーすべき3つの論理ブランチはまだありますが、信じています。最近の条件付きカバレッジ統計は完全に信頼できないものになっていると思います。 Java 8コードの条件付きカバレッジを測定するのは理にかなっていますか？十分にテストされていないコードを発見する他のツールはありますか？

19 java  unit-testing  test-coverage  java8 

私は、依存関係グラフをナビゲートし、依存関係のサイクルまたは矛盾を探す（再帰的）コードを書いています。ただし、これを単体テストする方法はわかりません。問題は、発生する可能性があるすべての興味深いグラフ構造のコードハンドルと、すべてのノードが適切に処理されるようにすることです。 通常、一部のコードが動作することを確信するには100％の回線またはブランチのカバレッジで十分ですが、100％のパスカバレッジであってもまだ疑問があるように感じます。 したがって、テストケースのグラフ構造を選択して、コードが実際のデータで見つかる可能性のあるすべての順列を処理できることを確信できるようにするにはどうすればよいでしょうか。 PS-問題がある場合、グラフ内のすべてのエッジに「必要」、「不可」のラベルが付けられ、自明なサイクルはなく、2つのノード間に1つのエッジしかありません。 PPS-この追加の問題ステートメントは、もともと質問の著者によって以下のコメントで投稿されました。 For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all must either use only edges labelled 'conflict' or 'requires'.

18 unit-testing  graph  test-coverage 

私はレガシーシステムで作業しています（つまり、テストなしで作成されたという意味です）。外部から機能をテストする統合テストを作成して、システムの一部をテストしようとしました。 これにより、コードの破損を心配することなく、コードの一部をリファクタリングする自信が得られます。しかし、問題は、これらの統合テストを実行するのに2分以上かかり、数分かかることです。また、それらは維持するのが苦痛です。それらはそれぞれ数千行のコードをカバーしており、そのうちの1つが壊れた場合、その理由をデバッグするのに1時間かかることがあります。 私は最近行ったこれらの機能変更のために多くの単体テストを書いてきましたが、コミットする前に常に新しいデプロイを行い、すべての統合テストを実行します。この時点で、ユニットテストと統合テストの一部がテスト内容と重複していることがわかりました。 統合テストを削除できるように、適切な単体テストが不適切な統合テストを適切にカバーしていることをどのようにして知ることができますか？

15 testing  unit-testing  integration-tests  test-coverage 

たとえば、コードが0〜10のランダムなintを生成し、結果ごとに異なる分岐を取る場合、そのようなコードで100％のステートメントカバレッジを保証するテストスイートをどのように設計できますか。 Javaでは、コードは次のようになります。 int i = new Random().nextInt(10); switch(i) { //11 case statements }

15 testing  test-coverage 

クラス/モジュール/パッケージ/などの内部/プライベートコンポーネントをどの程度単体テストしますか？それらをすべてテストしますか、それとも外部とのインターフェースをテストするだけですか？これらの内部の例は、プライベートメソッドです。 例として、1つの中央プロシージャから呼び出されるいくつかの内部プロシージャ（関数/メソッド）を持つ再帰降下パーサーを想像してください。外の世界への唯一のインターフェイスは中央の手順であり、文字列を受け取り、解析された情報を返します。他のプロシージャは文字列のさまざまな部分を解析し、中央プロシージャまたは他のプロシージャから呼び出されます。 当然、外部文字列をサンプル文字列で呼び出し、手で解析した出力と比較して、外部インターフェイスをテストする必要があります。しかし、他の手順はどうですか？それらを個別にテストして、サブストリングが正しく解析されることを確認しますか？ 私はいくつかの議論を考えることができます： 長所： より多くのテストが常に優れており、これはコードカバレッジの向上に役立ちます 一部の内部コンポーネントは、外部インターフェイスに入力を与えることにより、特定の入力（エッジケースなど）を与えるのが難しい場合があります。 より明確なテスト。内部コンポーネントに（修正された）バグがある場合、そのコンポーネントのテストケースは、バグがその特定のコンポーネントにあったことを明確にします 短所： リファクタリングは非常に苦痛で時間がかかります。何かを変更するには、外部インターフェースのユーザーが影響を受けていない場合でも、ユニットテストを書き直す必要があります 一部の言語およびテストフレームワークでは許可されていません あなたの意見は？

14 testing  unit-testing  test-coverage 

（これは良いインタビューの質問になると思いますが、私の場合はそれよりも実用的です。） 数十の化学成分間の非常に長く洗練された化学反応プロセスをモデル化する大規模で複雑なアプリケーションがあります。私たちは、アプリケーションの受け入れテストを設計する段階にありますが、テストするのに手に負えないほどの数の可能性のあるパスにやや気が進まないのです。私たちの状況は、Googleマップの開発チームが「ルートの取得」機能でルート計画アルゴリズムをテストするときに直面したものと非常によく似ていることがわかりました。明らかに、すべての可能なルートをテスト（検証および検証）することはできませんでした。では、どのような状況でもアプリケーションが機能するという自信をどのようにして得たのでしょうか？ そして、私は彼らがそれをどのようにしたかを知ることを期待していないので、あなたに尋ねましょう：特定のアプリケーションが堅牢であることを満足させるために、適切なコードカバレッジを備えたテストスイートをどのように設計しますか？システムを通るすべての潜在的な経路を調査するために？ 私が探しているのは、手に負えない問題を小さく扱いやすい部分に分解するために使用する原則です。その合計は、全体の満足のいく推定を提供します。「すべてをテストすることはできませんが、これをテストすることはできます、これ、そしてこれで十分です。」「確かに正しい」アプローチを探しているのではなく、実際の予算/時間の制約を考慮して、慎重なアプローチを探しています。 （Googleマップの例を使用して、できるだけ具体的な回答を求めています。）

13 acceptance-testing  test-coverage 

今、私は人々がこの質問を複製したり何度も質問したりすることを考えることができることを知っています。その場合、関連する質問へのリンクと私の質問への回答に感謝します。 私は最近、コードカバレッジについて何人かの人々と意見が分かれています。私は、100％のカバレッジは高品質のテスト、したがって高品質のコードを意味しないという議論に基づいて、チームにコードカバレッジを完全に削除することを希望する人々のグループがいます。 私は、コードカバレッジがテストされていないことを確かに伝えており、それらの領域に集中するのに役立つという議論を売り払うことによって押し戻すことができました。 （上記は、このような他のSO質問で同様の方法で議論されています-/programming/695811/pitfalls-of-code-coverage） これらの人々からの議論は次のとおりです。そして、チームは低品質のテストをすばやく作成することで反応し、重要な品質を追加することなく時間を無駄にします。 私は彼らの視点を理解していますが、より多くのカバレッジ基準を処理するより堅牢なツール/フレームワークを 導入することにより、コードカバレッジのより堅牢なケースを作成する方法を探しています(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc)。 私が探しているのは、このようなコードカバレッジツールとプラクティス/プロセスの組み合わせを提案して、それらに合うようにすることです。 主観的ではあるが、コードカバレッジによりコードの品質とテストの価値をより意識できるようになったため、このような議論に対抗する方法に関するあなたの経験/知識に基づいた付随するコメント/提案も歓迎します。 編集：典型的なコードカバレッジの弱さに対する私の理解に関する混乱を減らすために、ツール（または実行されたコードの行）を参照しているわけではない ことを指摘したいと思いStatement Coverageます（たくさんあります）。実際には、ここでそれが間違っているすべてに関する良い記事があります：http : //www.bullseye.com/statementCoverage.html 複数のカバレッジの基準とレベルにさらに踏み込んで、ステートメントまたはラインカバレッジ以上のものを探していました。 参照：http : //en.wikipedia.org/wiki/Code_coverage#Coverage_criteria アイデアは、ツールが複数の基準に基づいてカバレッジを教えてくれれば、それがテスト品質の合理的な自動評価になるということです。私は決して回線カバレッジが良い評価だと言っているわけではありません。実際、それが私の質問の前提です。 編集： わかりました、多分私はそれを少し劇的に投影しすぎたかもしれませんが、あなたはポイントを得ます。問題は、すべてのチームに共通のプロセス/ポリシーを同種/一貫した方法で設定することです。また、テストの品質をどのように保証するのか、何の対策も講じずに保証時間をどのように割り当てるのかという懸念が一般的です。したがって、適切なプロセスと適切なツールでバックアップすると、無駄なプロセスに時間を費やしていないことを認識しながら、コードの品質を改善できる測定可能な機能が好きです。 編集：これまでのところ私が答えから持っているもの： コードレビューは、テストの品質を確保するためにテストをカバーする必要があります Test First戦略は、事実の後に書かれたテストを回避して、カバレッジを単純に増加させるのに役立ちます％ 単純なステートメント/行以外のテスト基準をカバーする代替ツールの探索 カバーされたコード/見つかったバグの数の分析は、カバレッジの重要性を評価し、より良いケースを作るのに役立ちます 最も重要なことは、正しいことを行い、彼らの信念のために戦うというチームのインプットを信頼することです。 対象ブロック/テスト数-議論の余地あり これまで素晴らしい答えをありがとう。本当に感謝しています。このスレッドは、その能力を持つブレインストーミングの時間よりも優れています。

11 java  unit-testing  tools  test-coverage 

単体テストと統合テストの個別のコードカバレッジレポート、または両方のコードカバレッジレポートが必要ですか？ この背後にある考え方は、コードカバレッジにより、コードが可能な限りテストによってカバーされていることを確認できるということです（とにかく、マシンができる限り）。 個別のレポートがあると、単体テストでカバーされなかったこと、統合テストでカバーされなかったことを知るのに便利です。しかし、この方法では、総カバレッジ率を確認できません。

10 unit-testing  code-quality  integration-tests  test-coverage 

CI / CDワークフローでTDDにプッシュするために、いくつかの新しいプロジェクト用にBambooサーバーをセットアップしているところです。確かに、単体テストは素晴らしいですが、そこにあるのと同じくらいログだけです。 これは、特定のブランチ（つまり、開発ブランチとメインリリースブランチ）のGIT事前受信フックでより良いかもしれませんが、コードカバレッジを実施する場合は、どのように実施する必要がありますか。私はコミッターを信頼してコードがカバーされていることを確認できて嬉しいですが、勤勉さと一貫性を除いて、これらの事柄をどのように維持するのでしょうか？ 要するに、コミット段階またはビルド段階のいずれかで、他の人がどのようにテストカバレッジを自動プロセスとして実施するかを確認したいと思います。

9 unit-testing  test-coverage