100％のコードカバレッジはパイプの夢ですか？
重いjquery/backbonejs Webアプリケーションで100％のコードカバレッジを期待することは可能ですか？実際のコードカバレッジがjavascript/jqueryで約92％〜95％ホバリングするときに100％のカバレッジが満たされないため、スプリントに失敗するのは妥当ですか？
それは非現実的であるのと同じくらい現実的です。
現実的
コードベース全体をカバーすることが示されている自動テストを行っている場合は、100％カバレッジを主張するのが妥当です。
また、プロジェクトの重要度にも依存します。重要度が高いほど、完全なコードカバレッジを期待/要求することが合理的です。
小規模から中規模のプロジェクトでは、これを行う方が簡単です。
非現実的
0％のカバレッジから始めています...
プロジェクトは巨大で、再作成またはトリガーするのが難しい多くのエラーパスがあります。
経営陣はカバレッジが存在することを確認するためにコミット/投資することに消極的です。
取材なしからまともなプロジェクトまで、さまざまなプロジェクトに取り組んできました。 100％のプロジェクトは決してありませんが、100％に近い範囲をカバーしたいと思ったことは確かにありました。
最終的に問題は、既存の補償範囲が、チームが製品の出荷を快適にするために必要なケースを十分に満たしているかどうかです。
失敗がプロジェクトに与える影響はわかりません。そのため、92％または95％で十分か、それとも100％が本当に必要かはわかりません。あるいは、100％完全にあなたが期待するすべてをテストします。
誰がテストをテストしますか？
理論的にもナイーブであり、非現実的であり、 非現実的ビジネスの意味で。
- 循環的複雑度が高いコードでは非現実的です。すべての組み合わせをカバーするには変数が多すぎます。
- 非常に並行しているコードでは非現実的です。コードは確定的ではないため、テストの実行ごとに動作が変わるため、発生する可能性があるすべての条件をカバーすることはできません。
- ビジネスの意味では非現実的であり、クリティカルパスコードであるコード、つまり重要で頻繁に変更される可能性のあるコードのテストを作成することは、実際に利益を生むだけです。
コードのすべての行をテストすることは良い目標ではありません
テストを書くのは非常にコストがかかります。自分で書いてテストする必要があるコードです。実際にテストしようとしていることを文書化する必要があるコードです。ビジネスロジックの変更に合わせて維持する必要があるコードです。テストは古くなっているため失敗します。自動テストとそれらに関するドキュメントの保守は、コードを保守するよりも費用がかかる場合があります。
これは、単体テストと統合テストが役に立たないと言っているのではなく、それらが理にかなっている場合に限られます。人々を殺すことができる業界以外では、コードベースのコードのすべての行をテストしてみることは意味がありません。これらの致命的な殺害の外では、多くの人々が迅速にコードベースをコーディングしますが、100％のコードカバレッジが必要とする投資収益率を計算することは不可能です。
停止の問題：
計算可能性理論では、 停止問題 は、任意のコンピュータープログラムの記述と入力から、プログラムが実行を終了するか、永久に実行し続けるかを決定する問題です。
アランチューリングは、1936年に、可能なすべてのプログラムと入力のペアの停止問題を解決する一般的なアルゴリズムは存在できないことを証明しました。証明の重要な部分は、チューリングマシンとして知られるようになったコンピューターとプログラムの数学的定義でした。停止の問題はチューリングマシンでは決定不可能です。これは、意思決定問題の最初の例の1つです。
あなたは何かが100％機能することを証明することさえできないので、なぜそれをあなたの目標にしますか？
単純明快で、ほとんどの場合、ビジネス上意味がありません。
ほとんどの場合、100％のコードカバレッジは、少し「だまされた」ことを意味します。
- システムの複雑で頻繁に変更される部分（GUIなど）は、宣言型テンプレートまたはその他のDSLに移動されました。
- 外部システムに関連するすべてのコードは、ライブラリによって分離または処理されています。
- 同じことが他の依存関係、特に副作用を必要とする依存関係にも当てはまります。
基本的に、テストが難しいパーツは、必ずしも「コード」としてカウントされない領域に分路されています。常に現実的であるとは限りませんが、テストの支援とは関係なく、これらのすべてのプラクティスにより、コードベースの作業が容易になります。
100％ブランチカバレッジの印象的な実世界の例については、 How SQLite is Tested を参照してください。
まったく別の種類のソフトウェア製品であるjavascriptについて具体的に質問されていることは承知しておりますが、十分な動機をもってできることを認識させたいと思います。
特定のアプリケーションのすべての部分のユニットテストの100％コードカバレッジは、新しいプロジェクトであっても、夢のようなものです。私はそれが事実であることを望みますが、外部の依存関係を抽象化しようとするのがどれほど困難であっても、コードの一部をカバーできないことがあります。たとえば、コードでWebサービスを呼び出す必要があるとします。 Webサービスの呼び出しをインターフェースの背後に隠して、その一部をモック化し、Webサービスの前後にビジネスロジックをテストできます。しかし、Webサービスを呼び出す必要がある実際の部分は、ユニットテストすることはできません（とにかく非常にうまくいきます）。別の例は、TCPサーバーに接続する必要がある場合です。TCPサーバーに接続するコードをインターフェースの背後に隠すことができます。しかし、 TCPサーバーは物理的に接続できません。なんらかの理由でサーバーがダウンしていると、ユニットテストが失敗するためです。ユニットテストは、いつでもパスする必要があります。呼び出されました。
目安としては、すべてのビジネスロジックに100％のコードカバレッジが必要です。しかし、外部コンポーネントを呼び出す必要がある部分は、可能な限り100％に近いコードカバレッジを持つ必要があります。あなたが届かないなら、私はそれをあまり汗をかきません。
さらに重要なのは、テストは正しいですか？彼らはあなたのビジネスと要件を正確に反映していますか？コードカバレッジを取得するためだけにコードカバレッジを設定しても、間違ったテストを行ったり、誤ったコードをテストしたりしているだけでは、何の意味もありません。そうは言っても、あなたのテストが良ければ、92-95％のカバレッジを持つことは優れています。
100％のテストカバレッジを許可するという特定の目的でコードが設計されていない限り、100％は達成できない可能性があります。その理由の1つは、防御的にコーディングする場合（そうする必要があります）は、システムの知識があれば、発生してはならない、または発生しないはずの状況を処理するコードが必要になることがあります。そのようなコードをテストでカバーすることは、定義上非常に難しいでしょう。そのようなコードを持たないのは危険かもしれません-もしあなたが間違っていて、この状況の場合はどうでしょう 256回に1回 ？無関係な場所に変更があり、不可能を可能にした場合はどうなりますか？などだから、「自然な」手段では100％に到達するのがかなり難しいかもしれません-たとえば、メモリを割り当てるコードがあり、それが失敗したかどうかをチェックするコードがある場合、メモリマネージャーをモックアウトしない限り（簡単ではないかもしれません）そして、「メモリ不足」を返すテストを書いて、そのコードをカバーするのは難しいかもしれません。 JSアプリケーションの場合、さまざまなブラウザーで発生する可能性があるDOMの癖、外部サービスで発生する可能性のある障害などに関する防御的なコーディングである可能性があります。
ですから、100％にできるだけ近づくように努力すべきであり、デルタの正当な理由があると思いますが、必ずしも失敗として正確に100％が得られないわけではありません。 5％が何であるかに応じて、95％は大規模プロジェクトで問題ありません。
新しいプロジェクトを開始していて、厳密にテストファーストの方法論を使用している場合は、テストが完了した時点ですべてのコードが呼び出されるという意味で、コードカバレッジが100％であることがまったく妥当です。実行されました。ただし、メソッドの可視性により、個々のメソッドまたはアルゴリズムを直接明示的にテストしなかった場合や、間接的にさえ一部のメソッドをテストしなかった場合があります。
コードの100％をテストすることは、特にこの目標を達成できるようにシステムを設計していない場合や、設計作業をテスト容易性に焦点を合わせている場合は、おそらく十分な注意を払っていないため、コストがかかる可能性があります。特定の要件を満たすようにアプリケーションを設計すること、特にプロジェクトが大規模な場合。申し訳ありませんが、妥協することなく、両方を実現することはできません。
以前にテストが維持されていない、または含まれていない既存のプロジェクトにテストを導入する場合、労力を上回る演習のコストなしに100％コードカバレッジを取得することは不可能です。最も期待できる最善の方法は、最も頻繁に呼び出されるコードの重要なセクションにテストカバレッジを提供することです。
実際のコードカバレッジがjavascript/jqueryで約92％〜95％ホバリングするときに100％のカバレッジが満たされないため、スプリントに失敗するのは妥当ですか？
ほとんどの場合、目標を達成していない場合にのみ、スプリントが「失敗」したと見なす必要があると私は言います。実際には、次のスプリントを定義するときに計画を正しく行うために、期待を満たさないスプリントから学ぶことができる必要があるため、スプリントが失敗したとは考えない方がよいでしょう。いずれにせよ、コードカバレッジをスプリントの相対的な成功の要因と見なすことは合理的ではないと思います。あなたの目的は、すべてを指定どおりに機能させるのに十分なことです。テストを最初にコーディングする場合は、テストがこの目的をサポートすることを確信できるはずです。追加する必要があると思われる追加のテストは、事実上、糖衣であり、したがって、追加の費用がかかるため、スプリントを十分に完了することができません。
もちろんこれはしませんが、2つの大きなプロジェクトで行っています。とにかくユニットテストのフレームワークを設定している場合、厳密には難しくありませんが、合計すると多くのテストになります。
あなたが遭遇している最後の数行を打つことを妨げている特定の障害はありますか？そうでない場合、95％から100％のカバレッジを取得するのは簡単なので、そうすることもできます。あなたがここで質問しているので、私はisがあると仮定します。なにそれ？
Martin Fowlerは 彼のブログ ：I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.
ただし、ユニットレベルで100％の適用範囲を義務付ける基準さえあります。たとえば、ヨーロッパの宇宙飛行コミュニティの標準（ECSS、欧州宇宙標準化協力機構）の要件の1つです。リンクされた紙 here は、すでに完成したソフトウェアで100％のテストカバレッジを達成することを目標としたプロジェクトの興味深い話を伝えています。これは、単体テストを開発した関連エンジニアとのインタビューに基づいています。
レッスンの一部は次のとおりです。
- 100％のカバー率は珍しいですが、達成可能です
- 100％のカバー率が必要な場合があります
- 100％カバレッジは新しいリスクをもたらします
- 100％メトリックを最適化しない
- カバレッジを最大化するための適切な戦略を開発する
- 100％のカバレッジは良い品質のための十分な条件ではありません
92％で結構です。本当の質問は次のとおりだと思います：
現在、92％は「新しい」基準ですか？次のスプリントに88％のテストがある場合、それは大丈夫ですか？多くの場合、これは放棄されたテストスイートの始まりです。
ソフトウェアが機能し、バグがないことがどれほど重要か。 「テストのため」ではなく、これらの理由のためのテストがあります
戻って不足しているテストを埋める計画はありますか？
なぜテストするのですか？焦点は機能ではなくカバーされる行の％のようです
おそらく、実現可能かつ合理的であるかどうかを尋ねることは、尋ねるのに最も役立つ質問ではありません。おそらく最も実用的な答えは受け入れられたものでしょう。これをより哲学的なレベルで分析します。
100％のカバレッジが理想的ですが、理想的には不要であるか、実現がはるかに簡単です。それが実現可能であるか合理的であるよりも、それが自然で人間的なものであるかどうかについて考えることを好みます。
正しくプログラミングするという行為は、今日のツールではほぼ不可能です。完全に正しく、バグのないコードを書くことは非常に困難です。それは自然なことではありません。そのため、他に明白なオプションはありませんが、TDDや追跡コードカバレッジなどの手法に目を向けます。しかし、最終的な結果が不自然なプロセスである限り、人々に一貫して幸せにそれを実行させるのは難しいでしょう。
100％のコードカバレッジを達成するのは不自然な行為です。ほとんどの人にとって、それを成し遂げることを強制することは一種の拷問でしょう。
自然なメンタルモデルに対応するプロセス、ツール、言語、コードが必要です。これを怠った場合、製品の品質をテストする方法はありません。
今日そこにあるすべてのソフトウェアを見てください。そのほとんどはかなり定期的に混乱します。これを信じたくありません。私たちは私たちのテクノロジーが魔法であり、私たちを幸せにしたいと考えています。そして、私たちは無視し、言い訳をし、そして私たちの技術が混乱するほとんどの時間を忘れることを選びます。しかし、私たちが正直に物事を評価すると、今日そこにあるほとんどのソフトウェアはかなり安っぽいです。
コーディングをより自然にするためのいくつかの取り組みを次に示します。
https://github.com/jcoplien/trygve
https://github.com/still-dreaming-1/PurposefulPhp
後者は非常に不完全で実験的なものです。実は私が始めたプロジェクトですが、時間をかけて完成させることができれば、プログラミングの技術にとって大きな一歩になると思います。基本的に、コントラクトが気になるクラスの動作の唯一の側面を表現し、コントラクトをコードとして既に表現している場合、コントラクトに加えてクラスとメソッドの定義だけではないという考えです。このように、コントラクトはコードであり、すべてのメソッドを実装する必要はありません。図書館が私たちのために契約を守る方法を見つけましょう。