Zenn
😽

コードの複雑度とテスト容易性を改善するためのアプローチ

2024/11/08に公開
リファクタリング
cyclomaticcomplexi
tech

コードの複雑度とテスト容易性を改善するためのアプローチ

ソフトウェア開発において、 コードの複雑度 は保守性やテストのしやすさに大きな影響を与える要素です。
コードが複雑になりすぎると、テストするためのパスが増加し、すべてのケースをカバーするためのテストが非常に困難になります。
このような状況は、 サイクロマティック複雑度 という指標を使って測ることができ、複雑度が高いコードではテストの労力も大きくなります。

サイクロマティック複雑度とは

サイクロマティック複雑度は、コード内の独立した実行パスの数を表す指標で、条件分岐やループ、例外処理などが増えると比例して複雑度も増加します。
たとえば、条件分岐やエラーハンドリングを多用しているコードは、複数の経路が存在するためにサイクロマティック複雑度が高くなり、それぞれの経路をテストするためのパスも増えていきます。
複雑度が高いと、コードの理解が難しくなり、テストの網羅性も確保しにくくなるため、バグの発見や修正が難しくなります。

リファクタリングによる改善と限界

コードの複雑度がテストに与える影響を軽減するためには、テストがしやすくなるようにコードを整理することが重要です。
リファクタリングを活用することで、コードをよりわかりやすく、管理しやすくできます。

リファクタリングの効果として、以下の点が期待できます：

  • 可読性の向上 ： コードの理解が容易になり、問題の特定や修正がスムーズになります。
  • テストの効率化 ： 各関数やモジュールごとにテストが分割しやすくなり、実際にテストが必要な範囲を管理しやすくなります。
  • コードの重複や冗長性の削減 ： 処理を共通化し、冗長な部分を整理することで、コード全体が簡素化され、テストケースの作成や修正がスムーズになります。

ただし、 リファクタリングによってテストパス数（すべての実行経路を網羅するために必要なテストケース数）が減るわけではありません 。
リファクタリングはあくまでコードの構造を整理し、複雑度を見通しやすくするものであり、実行パスの数には影響を与えません。
そのため、リファクタリングによってテストはやりやすくなる一方で、パス数自体が減ることはないのです。

パス数と仕様の関係

テストパス数を本質的に減らすためには、仕様や要件の見直しが必要です。
テストパスはコードの分岐や条件に依存しており、仕様の内容を簡素化しない限り、パス数自体は変わりません。
たとえば、次のような仕様の見直しが、テストパス数の削減に寄与することがあります：

  • 不要な条件分岐や複雑なロジックを削減する
  • 必要な機能をシンプルに設計する
  • 並列処理や複雑な依存関係を最小限にする

ただし、これらの変更はシステム全体の動作やユーザーの期待に影響を及ぼす可能性があるため、慎重に検討する必要があります。

まとめ

サイクロマティック複雑度を抑えるためのリファクタリングによって、コードの保守性やテスト容易性が向上します。
わかりやすい構造にすることで、バグの早期発見や修正の効率化に繋がります。
しかし、テストパス数そのものを減らしたい場合は、リファクタリングだけでは不十分であり、仕様や要件の見直しが必要です。
このように、コードの整理と仕様の調整のバランスが、テスト容易性を向上させるための鍵となります。

Appendix: 条件分岐、ループ、例外処理が複雑度を増やすサンプルコード

以下のコードは、条件分岐、ループ、例外処理がどのようにサイクロマティック複雑度を増やし、テストパス数を増加させるかを示す例です。

func ProcessOrder(order Order) {
    // 条件分岐1：在庫があるかどうかを確認
    if order.Quantity <= checkInventory(order.ProductID) {
        // 条件分岐2：特別会員の場合、割引適用
        if order.IsSpecialMember {
            applyDiscount(order)
        }

        // ループ：商品を個別に処理（例えば、パッケージング）
        for i := 0; i < order.Quantity; i++ {
            packageProduct(order.ProductID)
        }
    } else {
        // 例外処理：在庫不足
        logError("Insufficient inventory for product", order.ProductID)
    }
}

このコードにおける複雑度の増加要因

  1. 条件分岐1 ： 在庫チェックの条件 if order.Quantity <= checkInventory(order.ProductID) によって、在庫が足りる場合と足りない場合の2つのパスが生まれます。
  2. 条件分岐2 ： 特別会員であるかの判定 if order.IsSpecialMember により、会員か会員でないかでさらに2つのパスが追加されます。
  3. ループ ： for ループ内の packageProduct(order.ProductID) により、商品数分だけ処理が繰り返されます。これにより、商品数に応じたテストケースが必要になります。
  4. 例外処理 ： 在庫不足が発生した場合の logError により、異常系のケースが追加され、さらにパスが増えます。

このコードのサイクロマティック複雑度の計算

  • 条件分岐1 (if order.Quantity <= checkInventory(order.ProductID)) ： 2パス
  • 条件分岐2 (if order.IsSpecialMember) ： 2パス（在庫が足りる場合のみ）
  • ループ ： （回数によりパスが増える）
  • 例外処理 ： 1パス（在庫不足の場合）

たとえば、在庫が十分にあり、特別会員でない場合、そして order.Quantity が 3 の場合、すべてのケースを網羅しようとすると以下のテストパスが必要です：

  1. 在庫が足り、特別会員であり、for ループが 3 回実行されるケース
  2. 在庫が足り、特別会員でない場合のループ実行ケース
  3. 在庫が足りない場合（例外処理）

このように、条件分岐、ループ、例外処理が増えるごとにパス数が増加し、テストの複雑度も上がります。

このコードのリファクタリング

このコードのサイクロマティック複雑度を減らすために、いくつかのリファクタリングを適用してみます。
以下の変更により、テストのしやすさが向上し、可読性も向上しますが、リファクタリングでは 実行パスの数自体は変わりません 。

func ProcessOrder(order Order) {
    if !hasSufficientInventory(order) {
        logError("Insufficient inventory for product", order.ProductID)
        return
    }

    applyDiscountIfSpecialMember(order)
    packageOrderItems(order)
}

func hasSufficientInventory(order Order) bool {
    return order.Quantity <= checkInventory(order.ProductID)
}

func applyDiscountIfSpecialMember(order Order) {
    if order.IsSpecialMember {
        applyDiscount(order)
    }
}

func packageOrderItems(order Order) {
    for i := 0; i < order.Quantity; i++ {
        packageProduct(order.ProductID)
    }
}

リファクタリングによる改善点

  1. 可読性の向上 ： ProcessOrder 関数から個別のロジック（在庫チェック、割引適用、パッケージング）を別関数に分離したことで、関数の意図がより明確になりました。
  2. コードの整理とテストの分割 ： 各機能が独立した関数として定義されたことで、個別の関数ごとに単体テストを作成できるようになり、テストの構造がシンプルになりました。
  3. 冗長な条件チェックの整理 ： hasSufficientInventory を導入し、在庫不足の処理を早期リターンする形にすることで、コードの流れがわかりやすくなりました。

リファクタリング後も変わらないテストパス数

リファクタリング後も、元の処理ロジックや条件分岐の内容には変更がないため、 実行パスの数（サイクロマティック複雑度）自体は変わっていません 。
次のテストケースは依然として必要です：

  1. 在庫が足り、特別会員であり、複数の商品をパッケージングするケース
  2. 在庫が足り、特別会員でなく、複数の商品をパッケージングするケース
  3. 在庫が不足している場合（異常ケース）

このように、リファクタリングによってコードは読みやすく、テストも行いやすくなりましたが、テストパス数自体を減らしたい場合には、 仕様や要件の見直しが必要 となります。

GitHubで編集を提案

Discussion