2

Groovy コードでは、 や など、いくつかの AST 変換を使用し@ToStringます@EqualsAndHashCode。これらを使用しているため、保守やテストを行う必要はありません。問題は、コード カバレッジ メトリクス (現在は jacoco を使用していますが、それが役立つ場合は変更可能です) は、これらが自動生成されたメソッドであることを認識しておらず、多くのコードが実際に作成しているコードではないにもかかわらず、カバーされていないように見えることです。

ツールのカバレッジ メトリックからこれらを含める方法はありますか?

単体テストはこれらのメソッドがどのように作成されるかを気にするべきではなく、それらが機能することだけを気にする必要があるため、注釈を付けているので、生成されるコードをテストする必要があると主張できると思います。

4

1 に答える 1

2

@Log とそれがコードに挿入する条件についても同様の問題がありました。これは、ブランチ カバレッジの欠如として報告されます (cobertura)。

しかし、あなたが言ったように、正しく報告するだけです。コードは対象外です。

コードが必要ない場合は、コードを生成しないでください。それが必要で、完全なテスト カバレッジを目指す場合は、それをテストするか、少なくとも「実行」する必要があります。

テスト方法論の観点からは、生成されたコードをカバーしないことは、除外パターンを使用することと同様に問題があります。実用的な観点からは、それと一緒に暮らしたいだけかもしれません。

于 2013-09-18T22:56:49.437 に答える