5

いくつかの決定点を別のメソッドにリファクタリングすることで CC を減らすプライベート メソッドを使用すると、実際のメソッドの CC が減り、読みやすくなりますが、テストで完全なブランチ カバレッジを得るための労力は減りません。

これは正当化できますか?フィールド経験は?

4

6 に答える 6

3

それでも興味がある場合は、循環的複雑性について書き留めたこの記事があります。

コードをさまざまな方法でカットしても複雑さは軽減されませんが、ローカルでより良い組織を持つのに役立つだけです。CC を削減する唯一の現実的な方法は、実際にリファクタリングすることです。

メソッドのみを抽出する場合は、同じ量のテストが必要になります。あなたのデータ構造を見て、彼らがあなたを助けていないかもしれませんか? センスがある場合は、いくつかのクラスに分割することも検討してください。

于 2012-05-04T13:24:14.597 に答える
2

場合によっては、アプリケーションコードをより複雑で読みにくくすると、テストコードがより複雑で読みにくくなることがあります。ただし、それはリファクタリングを行わない理由ではありません。実動コードの可読性は、テストよりも重要です。

CCを減らして読みやすさを向上させるためにいくつかのメソッドをプライベートにすると、Mockitoのようなフレームワークを使用して、プライベートメソッド自体をテストできるようになります。

于 2011-04-18T15:45:59.140 に答える
2

私の経験では、これは非常に一般的な状況です。実稼働コードを正しく実行させると、テストが難しくなります。
他の例としては、実装の詳細をインターフェイスの背後に隠す、ORM エンティティを外部の呼び出し元に到達させない、特定の機能を Web サービス呼び出しでのみ利用できるようにするなどがあります。 ..そして一般的に、本番環境で期待される API を使用すると、テストが頻繁に制限されます。

そして、はい、大幅なリファクタリングの後でカバレッジを取り戻すのは面倒です。テストが非常に難しい機能が適切にテストされていない場合、全体的な進行状況が逆になることがあります。したがって、最後の文を除いて、私はフォルテガにほぼ同意します。テストを腐らせないでください。あなたがそれを最も望んでいないときに彼らは戻ってきます。

于 2011-04-18T16:08:08.210 に答える
2

私はあなたの問題を本当に理解していません。明らかに、大規模なメソッドからプライベート メソッドにロジックと決定ポイントをリファクタリングすると、大規模なメソッドの循環的複雑度が減少します。これは、メソッドを抽出するポイントのようなものです。これにより、大きなメソッドがより短くシンプルになり、理解と変更が容易になることが期待されます。

不正行為ではなく、単にプログラムの構造を明示的にしているだけです。

ただし、テストでブランチを完全にカバーするための労力が減ることはありません。

これは私には不公平に思えます。プライベート メソッドを除外すると、カバレッジ テストが容易になるのはなぜですか? と主張する人を見たことがありません。もしかして何か勘違いしてませんか?

于 2011-04-18T17:19:49.373 に答える
1

メトリクスが吐き出す数値を改善することはコードにとって良いことであるという認識があるため、コードをリファクタリングするべきではありません。数値や手の込んだレポートを求めるよりも (残念ながらこれが行われているのを見たことがあります)、メトリックとそれが最初に使用される理由を理解することを目指す必要があります。

循環的複雑度は、すべての分岐がナビゲートされた場合にコードが実行できる異なるパスの数のみを示す単純な数学的尺度です。そうです、Cyclomatic Complexity が高いということは、テストがより複雑になる可能性があることを実際に示しています。しかし、高い CC と大規模なテストを伴うコードを作成する簡単な方法がない場合があります。これが公正な慣行である場合と、設計に何か問題がある場合を知る必要があるだけです。余談ですが、コードをメソッドに分割して CC を減らしても、コードをいずれかの方法でカバーする必要があるため、テストのタスクはまったく簡単になりません。「きれい」に見えるのは数字だけです。

次のことを考慮してください。キーの押下に反応し、押されたキーに応じて何らかのタスクを実行するコードを設計する必要があります。このデバイスには一定数のボタンしかありません。つまり、ソフトウェアは最初から網羅的である必要があり、拡張可能である必要はありません (そのコマンド パターンを使用してください)。

switchボタンを押すごとに 1 つのメソッドをトリガーする、読みやすい単純なステートメントを作成できます。これは、このタスクを迅速かつ効率的に解決するための良い方法です。しかし、キー プレスを取得するメソッドの CC は恐ろしいものです。コードを分割する必要がありますか? なんで?つまり、読みやすく、目的を完全に果たし、何を行っても、ボタンを押すたびにテストを行う必要があります。したがって、その数を減らす以外にリファクタリングのメリットはありません。

私のアドバイスは、循環的複雑度が意味のある指標である場合とそうでない場合を学ぶことです。また、Micheal のブログ投稿からリファクタリングのアドバイスをいくつか試してください。しっかりとしたアドバイスがあります。

于 2014-06-04T12:34:47.340 に答える