コードカバレッジを改善するために実際に使用したテクニックは何ですか？

Question

私は定期的にTDDを使用してライブラリの100％のカバレッジを達成していますが、常にではなく、テストされずに発見されたアプリケーションの一部が常に残っているようです。
次に、テストが非常に少なく、カバレッジが非常に少ないレガシーコードで開始する場合があります。

あなたの状況が何であり、少なくとも改善されたカバレッジについては何が機能しているのかを言ってください。
単体テスト中にカバレッジを測定していると仮定していますが、他の手法を使用している場合は言ってください。

Answer 1

コードを削除します。

これは気味の悪いことではありませんが、実際には深刻です。コードの重複や、実行することができなかったコードの最小量を見るたびに、それを削除しました。これにより、カバレッジと保守性が向上しました。

これは、新しいコードベースよりも古いコードベースのカバレッジを拡大する場合により適していることに注意してください。

Answer 2

＆quot; カバーされているコードとテストされているコード＆quot; 、そうですか？

その質問で述べたように、

  

100％のブロックカバレッジ+ 100％のアークカバレッジ+ 100％のエラーのない少なくとも1つのパスの直線コードでも、パス/ループを実行する方法で入力データが存在しますその他のバグ。

今、EMMAに基づいて eclemma を使用し、そのコードカバレッジツールが100％コードの理由を説明します常に可能であるとは限りません： 部分的に覆われた行 の原因：

• 同じ行の暗黙的なブランチ。
• 共有コンストラクタコード。
• finallyブロックによる暗黙的なブランチ。
• 非表示のClass.forName（）による暗黙的なブランチ。

したがって、これら4つのケースはすべて、リファクタリングの良い候補となり、コードカバレッジが向上します。

今、フランク・クルーガーの答えに同意します。いくつかのカバーされていないコードは、実際に削除するコードなど、リファクタリングが行われていることを示している可能性があります;）

Answer 3

私が取り組んできたプロジェクトに最も大きな影響を与えた2つのことは次のとおりです。

1. 定期的に「思い出させる」開発チームが単体テストを実際に実装し、効果的なテストの作成方法を確認します。
2. 全体的なテストカバレッジのレポートを生成し、それを開発マネージャーに配布します。

Answer 4

Perlを使用しているため、 Devel :: Cover は非常に便利です。米国。ユニットテスト中のステートメントごとのカバレッジ、ブランチカバレッジ、条件付きカバレッジ、およびPODカバレッジなどを表示します。 「100％」の緑がわかりやすいHTML出力を使用し、カバレッジのレベルが低い場合は黄色と赤を使用します。

編集：少し拡張するには：

• 条件付きカバレッジが完全でない場合は、相互依存の条件を調べます。ある場合は、リファクタリングします。そうでない場合は、テストを拡張してすべての条件を満たせるようにする必要があります。
• 条件カバレッジとブランチカバレッジが完全に見えてもステートメントカバレッジがそうでない場合は、条件を間違って記述した（たとえば、意図しないときに常にサブから早期に戻る）か、できる余分なコードがあります安全に削除されます。

Answer 5

FITテストにより、コードカバレッジが改善されました。それはまったく異なるタックであるため、素晴らしかったです。

背景：従来のコードと新しいコードが混在しています。できる限り新しいものを単体/統合テストしようとしていますが、Hibernate / Postgresに移行しており、OODBから離れているため、レガシーコードをテストする意味はあまりありません。

知らない人にとって、FITはユーザーの観点からソフトウェアをテストする方法です。基本的に、HTMLテーブルで目的の動作を指定できます。テーブルは、ソフトウェアに対するアクションと目的の結果を指定します。私たちのチームは、アクションをコードに対する呼び出しにマップする「グルーコード」（別名FITテスト）を作成します。これらのテストは、単体テストと比較して「宇宙から」のビューで動作することに注意してください。

このアプローチを使用して、コードカバレッジを数パーセントポイント増やしました。追加のボーナスは、これらのテストがバージョン間で橋渡しをすることです。レガシーコードをテストし、その後、新しいコードをテストします。つまり、ある意味で回帰テストとして機能します。