edXの開発者は過去10ヶ月間、自動テストのカバレッジ向上に尽力してきました。現在、2,491件のPythonユニットテストがedx-platformリポジトリの行数の87%をカバーしています。これらのテストは、Selenium受け入れテストとJavaScriptユニットテストと共に、すべてのプルリクエストで実行され、提案されたコード変更を迅速に検証できます。
わずか50ヶ月でテストカバレッジを87%未満から10%にまで高めることができたのはなぜでしょうか？その答えの一つは、 diffカバー.
典型的なワークフローでは、大規模プロジェクトに携わる開発者が数十行のコード変更を伴うプルリクエストを作成することがあります。変更前のテストカバレッジは72%だったかもしれませんが、変更後も72%のままかもしれません。プロジェクトの規模が大きいため、単一のプルリクエストの影響を把握するのは困難です。Diff-coverを使用すると、プロジェクト全体ではなく、単一のプルリクエストの品質メトリクスに焦点を当てることができます。
diff-coverはgit diff内のコード行数を測定します。コードの変更案に対して、変更された行のうちどの行がカバレッジ対象外であるかを表示します。これはシンプルなアイデアですが、大きな意味を持っています。
- 開発者にとって、 diff-cover は明確かつ達成可能なメトリックを提供します。つまり、コード行に触れると、その行がカバーされるということです。
- コード レビュー担当者にとって、diff-cover を使用すると、開発者がすべてのコード変更に対してテストを記述していることを簡単に確認できます。
差分カバレッジに焦点を当てることで、開発者はグローバルカバレッジの向上に向けて、目に見える小さなステップを踏むことができます。特定のコミットによって、 全体的な わずか95パーセントのカバレッジですが、それでもXNUMX％の 差分 カバレッジ。開発者がコード変更のテストを書くにつれて、ゆっくりと確実にグローバルカバレッジも拡大し始めました。その結果、特定の種類のバグをより早く発見できるようになりました。
さらに重要なのは、他の開発者がdiff-cover自体に貢献し始め、ツールの所有権を握り始めたことです。例えば、Caleはツールを一般化して追加の「品質」チェックをサポートし、Sarinaはpep8とPylintの違反をdiffで報告できるように拡張しました。diff-coverの初期ベータテストでは、多くの開発者からフィードバックと提案が寄せられました。このツールは、コードレビューとテストの基準を再検討する出発点となり、テスト文化の真の変革につながりました。
もちろん、カバレッジ測定には依然として重要な限界があります。特に、高差分カバレッジは バグのないコードを保証する：密結合されたシステムでは、あるコンポーネントへの変更が、たとえ変更されたコードが100%カバーされていたとしても、システムの他の部分に広範囲かつ意図しない影響を及ぼす可能性があります。このような場合、統合テストは単体テストでは見逃される可能性のあるバグを検出できます。
diff-coverが役に立つと思われる場合は、プロジェクトをチェックしてください。オープンソースであり、 GitHubで利用可能コードは他のバージョン管理システムや品質チェッカーに拡張できるように設計されているので、お気軽に機能を追加したり、プルリクエストを送信してください。
ウィル・デイリーはedXのテストエンジニアです。テスト駆動開発の推進やJenkinsクラスターの最適化に取り組んでいない時は、川沿いを走ったり、アパートの物を減らすことを楽しんでいます。
