ユニットテストを活用してリファクタリングの失敗を防ぐ方法：サンプルコードで学ぶ効果的な実践法

リファクタリングは、コードの可読性や保守性を向上させる重要な手法です。しかし、リファクタリングの過程で、機能に影響を与えるエラーを招いてしまうことも少なくありません。

この記事では、RPGゲームを題材としたC#のサンプルコードを通じて、リファクタリングのミスを防ぐためにユニットテストをどのように活用するかを学びます。

C#に限らず、他の言語でも応用できる内容ですので、ぜひご参考ください。

リファクタリングとユニットテストの重要性

リファクタリングは、コードの機能そのものに影響を与えず、構造や可読性、保守性を向上させるために行われるプロセスです。

これは、成長するコードベースを健全に保ち、開発スピードを維持するために非常に重要な手段です。しかし、リファクタリングの過程で新たな不具合が発生するリスクも伴います。

小さな変更でも意図せぬバグを生む可能性があり、リファクタリング後にその影響を確認しなければ、後々のデバッグが困難になる場合があります。

そこで役立つのがユニットテストです。ユニットテストは、コードの一部（ユニット）を独立して検証し、リファクタリングによる動作変更や意図しない影響を迅速に検知できるツールです。

テストによって現状のコードがどのように動作するべきかが明確になるため、リファクタリング後も期待通りの動作が維持されているかを確認できます。

ユニットテストが揃っていると、リファクタリング時にも安心してコードの改善が進められます。また、他の開発者がコードを更新した場合でも、ユニットテストによって変更の影響をすぐに確認できるため、プロジェクト全体の品質が保たれやすくなります。

ユニットテストはリファクタリングを支える重要な仕組みであり、バグの防止や安定性の維持、チーム全体での開発効率向上にも寄与します。

サンプルケースの紹介：RPGゲームのプレイヤークラス

RPGゲームの「プレイヤー」クラスを例に、リファクタリングを行いながらユニットテストを活用する方法を紹介します。

プレイヤークラスは、キャラクターの名前、HP（体力）、MP（魔力）、攻撃力などの属性を持ち、それに基づいて攻撃や魔法を使うメソッドを備えています。

悪い例のサンプルプログラム

ここでは、改善の余地がある「悪い例」のプレイヤークラスを紹介します。この例では、コードの重複やハードコードされた値、拡張性の低さなど、リファクタリングの対象となるポイントがいくつか含まれています。リファクタリングすることで、コードの可読性や柔軟性を向上させる余地が大いにあります。

public class Player
{
    public string Name;
    public int HP;
    public int MP;
    public int AttackPower;

    public Player(string name)
    {
        Name = name;
        HP = 100; // 固定値
        MP = 30;  // 固定値
        AttackPower = 10; // 固定値
    }

    public void Attack(Player enemy)
    {
        Console.WriteLine($"{Name} attacks {enemy.Name} with {AttackPower} power!");
        enemy.HP -= AttackPower;
    }

    public void CastMagic(int mpCost)
    {
        if (MP >= mpCost)
        {
            Console.WriteLine($"{Name} casts magic!");
            MP -= mpCost;
        }
        else
        {
            Console.WriteLine($"{Name} doesn't have enough MP!");
        }
    }
}

この悪い例のコードには、以下のような問題点があります。

ハードコードされた値：HP、MP、AttackPowerがすべてコンストラクタ内で固定されています。これにより、プレイヤーキャラクターのステータスを変更したい場合、コードを直接修正しなければならず、柔軟性に欠けています。
可読性と再利用性の低さ：このクラスは、他のプレイヤーキャラクターの種類や異なる属性のキャラクターを追加する際に使い回しが難しく、保守性が低いです。
ユニットテストが困難：現在のコード構造では、リファクタリング後の動作確認や変更による影響をテストすることが困難です。ユニットテストを行うには、可変な属性やインターフェース設計が必要です。

次のセクションでは、このコードに対してユニットテストを作成し、リファクタリングの準備を進めます。ユニットテストによって動作を確認しながら、コードの改善を行う方法について解説していきます。

ユニットテストの活用：リファクタリングによるミスの防止

リファクタリングを行う前にユニットテストを作成することは、リファクタリングによって意図しないバグが発生するのを防ぐ上で非常に重要です。ユニットテストによって、リファクタリングの前後で同じ動作が維持されていることを確認でき、コード改善のプロセスを安全に進めることができます。

ここでは、悪い例のプレイヤークラスに対してユニットテストを作成し、リファクタリング後の検証を簡単にするためのテストケースをいくつか紹介します。

using NUnit.Framework;

[TestFixture]
public class PlayerTests
{
    [Test]
    public void Attack_ShouldReduceEnemyHP()
    {
        // Arrange
        Player player = new Player("Hero");
        Player enemy = new Player("Monster");

        // Act
        player.Attack(enemy);

        // Assert
        Assert.AreEqual(90, enemy.HP);
    }

    [Test]
    public void CastMagic_ShouldReduceMP_WhenEnoughMP()
    {
        // Arrange
        Player player = new Player("Mage");

        // Act
        player.CastMagic(10);

        // Assert
        Assert.AreEqual(20, player.MP);
    }

    [Test]
    public void CastMagic_ShouldNotReduceMP_WhenNotEnoughMP()
    {
        // Arrange
        Player player = new Player("Mage");
        player.MP = 5;

        // Act
        player.CastMagic(10);

        // Assert
        Assert.AreEqual(5, player.MP);
    }
}

テストのポイント

このテストケースでは、プレイヤークラスの重要なメソッド（AttackとCastMagic）が正しく動作しているかを確認しています。

Attackメソッドのテスト：player.Attack(enemy)が実行されると、enemyのHPが減少することを確認しています。このテストによって、Attackメソッドが正しく敵のHPを減少させているかが検証できます。
CastMagicメソッドのテスト（MPが十分な場合）：プレイヤーが十分なMPを持っている場合に魔法を使用でき、指定されたMPが消費されることを確認しています。このテストによって、MPが減少する正しい動作が確認できます。
CastMagicメソッドのテスト（MPが足りない場合）：プレイヤーのMPが消費するコスト未満の場合、MPが減少しないことを確認します。これにより、MPが不足している場合のCastMagicメソッドの動作が検証できます。

ユニットテストを用いたリファクタリングの進め方

これらのユニットテストが準備できれば、リファクタリングを行ってもテストを通じてコードの動作が正しいことを確認できます。もしリファクタリングの過程で動作に影響を与える変更が加わってしまった場合、テストが失敗して問題点を指摘してくれます。こうして、リファクタリング後も同じ動作が維持されていることを保証でき、意図せぬバグが発生するリスクを低減できます。

まとめ

リファクタリングの必要性：コードの保守性や可読性を向上させるために重要だが、ミスが発生するリスクも伴う。
ユニットテストの役割：リファクタリングの前にユニットテストを作成することで、リファクタリング後も動作が維持されているかを確認できる。
悪い例のコードの問題点：
- ハードコードされた値が多く、再利用や拡張が難しい。
- ユニットテストが不十分なため、リファクタリング後の動作確認が困難。
ユニットテストの活用：リファクタリングに伴う不具合を防ぎ、コードの品質と一貫性を保つために重要。
良いコードの改善：柔軟で再利用性の高い構造を持ち、ユニットテストを通じて信頼性が向上する。