こんにちは、MLBお兄さんこと松村です。
大谷翔平選手が 45-45 (45本塁打-45盗塁) を達成しましたので、50-50 の達成が待ち遠しいです。
アプリケーション開発における単体テストは重要だと考えていますが、ちょっとしたことからテストが書けるようになろうと社内でちょいちょい話していることを文章化してみようと思います。
※あくまで松村の個人的見解です
小さく始める単体テスト
例として最適かどうかは置いといて、以下のようなクラスがあったとします。
public class User { }
見てわかるように、クラスが定義されていますが、プロパティやメソッドなどクラスとしての機能は定義されていません。
じゃあ、このクラスの単体テストが不要かといえば、個人的には必要だと考えています。
というのは「このクラスは”いま”機能がないだけ」という感覚があり、将来的にプロパティやメソッドが定義される可能性はゼロではないからです。
そのため上記の User
クラスに対しては、1つだけテストを書いておきます。
public class UserTest { [Fact] void 引数なしコンストラクタ() { User actual = new(); Assert.NotNull(actual); } }
User
クラスにプロパティやメソッドはありませんが、引数なしコンストラクタは利用可能です。
つまり User
クラスは new
でインスタンスを作成することができるため、「クラスを使う機会がある」と言えます。
なので単体テストとしては、上記のように引数なしコンストラクタで想定通りにインスタンスを作成できるかどうかを確認することができます。
機能が増えたらテストも増やす
クラスはいつまでも何も機能を持たないというのは考えにくいので、プロパティやメソッドもいずれ追加されます。
機能を追加したら、単体テストも都度増やしていきましょう。
public class User { public string Name { get; set; } } public class UserTest { [Fact] void 引数なしコンストラクタ() { User actual = new(); Assert.NotNull(actual); } [Fact] void Nameプロパティ() { User actual = new(); actual.Name = "Yuta"; Assert.NotNull(actual); Assert.Equal("Yuta", actual.Name); } }
データベースのためのエンティティクラスなどは、プロパティはあれどメソッドを定義しないという場面は少なからずあります。
最近では GitHub Copilot Chat の /tests
コマンドなど、AIを活用してテストコードも書きやすい環境が整いつつあります。
そういったテクノロジーを活用して、”小さな”クラスから単体テストを書くことに慣れていくとよいと思います。
サービス一覧 www.alterbooth.com cloudpointer.tech www.alterbooth.com