Kotlinのテストコードを読みやすくするベストプラクティス！初心者でも安心の書き方ガイド

先生と生徒の会話形式で理解しよう

生徒

「Kotlinのテストコードって、たくさん書いてくると読みにくくなりませんか？」

先生

「そうですね、読みやすいテストコードにするためには、いくつかのベストプラクティスを意識する必要がありますよ。」

生徒

「ベストプラクティスって何ですか？具体的に知りたいです！」

先生

「では、初心者でも理解しやすいように、Kotlinのテストコードを読みやすくするポイントを一緒に見ていきましょう！」

1. テストはシンプルに！一つのテストで一つの動作を確認

Kotlinのテストコードを書くときは、なるべく一つのテストメソッドで一つの機能だけを確認するようにしましょう。

たとえば、「数字を足す処理」と「マイナスの数字を扱う処理」は別々にテストすることで、どこが失敗したのかすぐにわかります。

これは、「責任の分離」と呼ばれる考え方で、コードを読みやすく・直しやすくする大切な習慣です。

2. テスト名で何をテストしているか明確に伝える

テストコードの中でも特に大事なのが「テストメソッドの名前」です。

名前を見ただけで「何を」「どういう条件で」「何を期待しているか」がわかるようにしましょう。

例としては以下のような書き方がよく使われます。

add_twoPositiveNumbers_returnsCorrectSum
shouldThrowExceptionWhenInputIsNull

日本語に訳すと、「2つの正の数を足すと正しく合計が返る」とか、「入力がnullのときに例外を投げるべき」という意味ですね。

3. 準備・実行・検証の順で書く（Arrange, Act, Assert）

テストコードを書くときには、以下の3つの流れを意識して書くと読みやすくなります。

Arrange（準備）：テストに必要なデータやオブジェクトを用意する
Act（実行）：テストしたい処理を実行する
Assert（検証）：結果が期待通りか確認する

これは英語で「3Aの原則」とも呼ばれていて、テストコードを整理して書くための基本ルールです。


@Test
fun add_twoPositiveNumbers_returnsCorrectSum() {
    // Arrange
    val calculator = Calculator()

    // Act
    val result = calculator.add(2, 3)

    // Assert
    assertEquals(5, result)
}

4. ダミーやスタブを使って依存関係を切り離す

本番コードでは他のクラスや外部サービスに依存していることがあります。

たとえば「データベース」や「Web API」などと連携している場合、それらに接続せずにテストだけしたいときがあります。

そんなときに便利なのが「ダミー（モック）」「スタブ」といったテスト専用の偽物です。

これにより、テストの範囲を限定しやすくなり、テストコードの信頼性と読みやすさが向上します。

5. テストデータは分かりやすい名前と値にする

たとえば、テストの中で使う変数名をxやyにすると、あとから見て意味がわかりません。

代わりに、priceやquantityなどの意味ある名前を使うと読みやすさが向上します。

また、値も適切な数値や文字列を使うようにしましょう。


@Test
fun calculateTotalPrice_withValidInput_returnsCorrectResult() {
    val price = 100
    val quantity = 3
    val result = price * quantity
    assertEquals(300, result)
}

6. テストコードにもコメントを入れよう

テストコードは自分のためだけでなく、チームの仲間や未来の自分のために書くものです。

何をしているか分かりやすくなるように、要所要所に簡単なコメントを入れると親切です。

特に例外処理のテストや、特殊なケースのテストでは、コメントがあると理解が深まります。

7. テストの失敗メッセージをわかりやすくする

assertEqualsなどの検証で、失敗したときのメッセージを指定できると便利です。

これにより、どんな条件で失敗したかがすぐに分かります。


assertEquals(300, result, "合計金額が正しくありません")

8. 不要な重複を避けるために共通処理をまとめよう

同じ処理を複数のテストメソッドで何度も書いている場合は、@BeforeEachという仕組みで共通の準備コードをまとめることができます。


lateinit var calculator: Calculator

@BeforeEach
fun setup() {
    calculator = Calculator()
}

こうすることで、テストの本質に集中しやすくなります。

9. テスト対象ごとにファイルを分ける

テストコードのファイル構成も重要です。1つのファイルにあれこれ詰め込むと、見通しが悪くなります。

たとえば、UserServiceをテストするならUserServiceTest.ktというファイルを作るのが一般的です。

テスト対象ごとにファイルを分けることで、ファイルを探しやすくなり、メンテナンス性も上がります。