Unit Test の改善に取り組んでみました

長友優治

2022.09.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

prismatix 事業部で QA エンジニアをしている長友です。

今回は私の所属するチームの方がテスト改善を行ってくださったので、そのお話です。

経緯

今私のいるチームには、私以外に K さんというメンバーの方がおられます。これまで私の所属する prismatix 事業部で、いろいろなマイクロサービスの開発に携われてきた方です。エンジニアリング力が高く、テストに関する本も出されている方で、私もその方の本を持っています。ですから話すときはよくテストの話題になります。

その方が、これまで開発チームにいた中で作っていたテストコードによるテストのやり方に課題を感じていたということで、今回その改善をすることになりました。いろいろ試行錯誤をされて、こうしたらいいのではないかというアイデアが出てきたので、それをどうやって開発チームに実践してもらうかをやってみたことをお話します。

なお、私の所属するチームは「チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計」という本にあるイネイブリングチームという位置づけになっていて、ストリームアラインドチーム（うちの部署では各マイクロサービスの開発チーム）の自律性を高めることを目標に活動をしています。

課題

K さんがチーム内でお話してくださった感じている課題感は、以下のようなものです。

これまでの UnitTest の中では、mock を多用している。そのため、

テストクラスがちょっとした内部の変更でも壊れやすくなっている
リファクタリングで注意が必要になり、その効果も得にくく、対応もしにくくなっている

ということが起こっている。

リファクタリングを行って、mock のシグニチャが変わった際にテストコードまで修正しないといけないことがある。本来リファクタリングで壊していないかをテストで確認するのに、そのテストコードを修正しているのは、テストが通るようにしているのだからテストが通るのは当たり前で違和感を感じる。

リファクタリングを行ってもテストコードを修正せずに、壊していないことを確認できることで、リファクタリングをしやすくなるようにしたい。

解決案

課題を解決するために、K さんがいろいろ検討してくださった案をチームで議論してみた結果、以下を試してみることになりました。

Service の UnitTest で実際のリポジトリを使い、その他に依存性注入（DI）しているものがあれば実際のオブジェクトを使う（外部サービスについては mock を使う）

これに伴い、public メソッドを経由したテストを実行するようにする。依存するクラスに対してのテストも同じように public メソッド経由で行えば、デグレの検知もしやすくなり、リファクタリングの本来のメリットを得やすい。

ただし、public メソッド経由にすることで、ブラックボックステストになるので、レビューする側が仕様を知らないとレビューが難しくなるということがあがりました。

こちらについては、事前にテスト観点とその観点から出てきたケースをスプレッドシートに整理する。それをもってレビューアと認識合わせを行うことにすればよいのではないかということになりました。

詳細

K さんにこのブログを書くにあたって、サンプルコードとともに簡単に解決案の詳細をいただきましたので、こちらに記載しておきます。

＝＝＝＝＝＝（ K さんからいただいた詳細）＝＝＝＝＝＝＝

スプレットシートは以下のような感じです。

テスト用スプレッドシート

テスト観点には「入力」と「出力」の2つのカテゴリがあります。それぞれのテスト観点に考えられるケースを記載します。

テストケースは列毎に表現します。例えば「Case1」では、

payment の status が AWAITING_AUTHORIZATION
payment.meta.status が AUTHORIZATION_REQUESTED

の時にテスト対象メソッドを呼び出すと、

正常レスポンスを返す
payment の status を CANCELLED, meta.status を CANCELLED に更新する

ことを表します。

このスプレットシートだけ見てもわからないかもしれませんが、コンテキストを共有できる開発者同士であればこれとテストクラスを見ればだいたい把握できるだろうという前提のもと、あまり時間をかけずに認識合わせができる資料を作ることを目的にしました。

実際のテストクラスは以下のようなイメージになります。

@DisplayName("XXXService の UnitTest")
class XXXServiceTest {

  private XXXService sut;

  @Nested
  @DisplayName("呼び出し時の payment の status が AWAITING_AUTHORIZATION、payment.meta.status が AUTHORIZATION_REQUESTED の時のケース")
  class Case1 {
    @Test
    @DisplayName("レスポンスの検証")
    void testResponse() {
      ...
    }

    @Test
    @DisplayName("payments 更新に対する永続化の検証")
    void testPaymentTable() {
      ...
    }
  }

  @Nested
  @DisplayName("呼び出し時の payment の status が AWAITING_AUTHORIZATION、payment.meta.status が AWAITING_AUTHORIZATION の時のケース")
  class Case2 {
    ...
  }
}

テストケース毎に Nested で class を作り、スプレッドシート側とテストケースを合わせるようにします。期待結果の観点毎にテストメソッドを作成して、テストメソッドで何を確認するかぶれないようにしています。

レビューはスプレッドシートとテストクラスを一緒にレビュー対象にします。実装前にスプレッドシートを作ったほうが早めに認識違いに気付けるとは思うのですが、今の所タイミングは任意です。この方法だと、テストクラスとスプレッドシートがずれる可能性はあるのですが、そこはレビューで見ていこう、という運用です。

＝＝＝＝＝＝（ K さんからいただいた詳細おわり）＝＝＝＝＝＝＝