何年も前に、Michelle Caiseは、lcovユーティリティに基づいてPostgreSQLコードベースのコードカバレッジレポートを生成するパッチを提出しました。メーリングリストのアーカイブに実際のパッチの記録は見つかりませんでしたが、Peter Eisentrautはしばらくしてそれをコミットし、後でさらに改良を加えました。
本日、新しいPostgreSQLコミュニティサービスを発表します。コードカバレッジレポートは、このインフラストラクチャを使用して自動的に生成され、毎日更新されます。このシステムはマスターブランチをコンパイルし、 make check-worldを実行します 、次に make Coverageを使用してHTMLレポートを生成します 、これが表示されます。
src / backend / access / brin
のサンプルコードカバレッジレポートコードカバレッジに慣れていない読者のために、簡単な要約：コードを実行するテストスイートがある場合、コードは「カバー」されます。カバーされていないコードは、誰にも気付かれずに簡単に壊れてしまう可能性があり、それは良くありません。コードが黙って壊れないようにするには、行の大部分がテストでカバーされていることが重要です。より完全な説明については、この件に関するウィキペディアのページをご覧ください。
この分野の統計は歴史的にかなり悪いものでした。多くのバックエンド機能は十分にカバーされていますが、部分的にしかカバーされていない機能もあれば、まったくカバーされていない機能もあります。近年、改善を続けています。最初に、分離テスターを追加しました。これにより、同時実行でのみ動作する機能をテストできるようになりました。次に、TAPテストを追加しました。これは、最初はクライアントユーティリティを対象としていましたが、後でWAL再生コードなどの他のものも対象とするように拡張されました。しかし、まだ長い道のりがあることは明らかです。
覚えておくべきいくつかの注意事項があります。 1つは、 make check-worldです。 ターゲット（このカバレッジツールが報告するもの）はbuildfarmが実行するものではないため、カバレッジレポートがbuildfarmよりも多くのテストを実行している場合があります。つまり、実際にはカバレッジがない状態でカバレッジを要求しています。もう1つは、カバレッジが単一のプラットフォーム（AMD64ではDebian）で実行されるため、他のアーキテクチャのコードはカバーされているとは報告されないということです。
だから外に出て探検してください！つまり、レポートを調べて、コードのどの部分がカバーされていないかを把握し、それを修正するためのテストを作成してみてください。興味を持ってpgsql-hackersでパッチをお待ちしています。
（また、 make check-world 以外に実行する必要のあるテストはありますか？ ？コメントにフィードバックを残してください。