読みづらい書きづらいテストコードを改善する話

アソビュー！ Advent Calendar 2023の19日目のブログです。

こんにちは！アソビューでバックエンドを担当している佐藤です。

テストコード書くの面倒ですが書かないと不安になりますね？！
でもやっぱり書くのは面倒ですよね...。読みづらいテストコードだと修正するモチベーションもさがります。

困っていたこと

私の所属するプロジェクト（Java）ではSpockを使ってテストコードを書いています。本来であればSpockを使うことでシンプルに記述できるはずなのですが、プロジェクトのルールとしてドメインにはLombokの@Valueアノテーションをつけることが必須となっています。つまりは@AllArgsConstructorも有効になっており、コンストラクタに全てのフィールドをセットしなければなりません。

テストで不要なフィールドにはダミーとしてnullをセットする必要があり何も考えずに書くと以下のように書く必要があります。

def salesProduct = new SalesProduct(
    null,
    null,
    null,
    null,
    salesProductImageUrl // テストで使うフィールド
)

本来Spockであればマップベースのコンストラクタを使うことで必要なフィールドだけセットすることで記述する量を大幅に減らすことができます。

def salesProduct = new SalesProduct(
    salesProductImageUrl: salesProductImageUrl
);

対策

一手間必要ではありますが、テストコードにGroovyのnamed parameterを使ってFactoryメソッドをつくることでSpockで書くマップベースのコンストラクタと似たような記述ができます。

def "テストその壱"() {
    given:
        def salesProduct = createSalesProduct(salesProductImageUrl: salesProductImageUrl)
    when:
        ....
    then:
        ....
}

def "テストその弐"() {
    given:
        def salesProduct = createSalesProduct(salesProductImageUrl: salesProductImageUrl)
    when:
        ....
    then:
        ....
}

def createSalesProduct(args) {
        return new SalesProduct(
                args.salesProductId ?: null,
                args.baseId ?: null,
                args.salesProductStatus ?: null,
                args.salesProductDescriptionTitle ?: null,
                args.salesProductImageUrl ?: null,
        )
    }

これでそれぞれのテストコードで必要なフィールドをセットするだけでよくなりテストコードを読むときの視認性があがると思います。

さいごに

実装のルール・制約（品質担保する上で必要なもの）、今回でいうとLombokを使うことでSpockのパワーが発揮できないわけですが、少しの手間で読みやすくメンテナンスもしやすくすることができました。
これからも少しずつ改善していけたらと思います！（統合テストもできるようにしたいな〜）

アソビューでは一緒に働くメンバーを募集しています。
Javaエンジニア大募集しているので、ぜひ採用ページをご覧ください！