テストにGiven-When-Then構文を用いてみるのはどうだろう

Given-When-Then構文（パターン）とは

テストコードを下記の3つのブロックに分けて書く記法。

• Given (前提条件)：操作を実行する前の状態
  • データやモックを作ったりするところ
• When (操作): 操作
  • メソッドを呼んだりするところ
• Then (結果) : 操作した結果
  • アサーションを呼ぶところ

例

百聞一見にしかず。
下記が例です。

Given-When-Then構文を用いない場合

object Utils {
    fun add_100(x: Int) = x + 100
}

class UtilsTest {
    @Test
    fun test_add_100() {
        val x = 1
        val result = Utils.add_100(x)
        assertEquals(101, result)
    }
}

Given-When-Then構文を用いた場合

object Utils {
    fun add_100(x: Int) = x + 100
}

class UtilsTest {
    @Test
    fun test_add_100() {
        // GIVEN
        val x = 1
    
        // WHEN　
        val result = Utils.add_100(x)

        // THEN 
        assertEquals(101, result)
    }
}

メリット

どこでなにをしているか、ひと目でわかるので可読性の向上に繋がります。

もちろん、Given-When-Then構文を用いなくてもテストは普通に読めます。
ただ、たまにとんでもないテストの書き方をする人がいるのと、どうしても長くて読みにくくなってしまうテストがあるので、そういう時のためにチームでGiven-When-Then構文使うというルールを設けるのはアリかなと思っています。

デメリット

（正直ないですけど、敢えて述べるなら）
コメントアウトでgiven when thenを書くので、１テストにつき最低でも３行はかさみます。笑
縦にコードが伸びるのが嫌な人には不向きかもしれません

まとめ

Given-When-Then構文を用いてテストコードの可読性高めてみません？