モック地獄と破壊的変更　〜Small, Medium Testってどのくらい細かく刻めば良いんだ？〜

April 24, 2019

この記事では、

Small Test: 関数、メソッド単位でのテスト
Medium Test: リポジトリ単位でのテスト

を想定して話します。

最近困っていること　〜モック地獄、破壊的変更とメンテナンス性〜

最近、apitestというテストツールを開発しています。 (現状はBDDブランチがメインなのでmasterはだいぶ前で止まっています) このリポジトリはテスト用ツールのくせに、Small TestのC0が

$ go test ./... --cover
ok  	github.com/aimof/apitest	(cached)	coverage: 0.0% of statements [no tests to run]
ok  	github.com/aimof/apitest/cmd/apitest	0.003s	coverage: 0.0% of statements
ok  	github.com/aimof/apitest/comparer/jsoncomparer	0.002s	coverage: 62.3% of statements
ok  	github.com/aimof/apitest/kicker	(cached)	coverage: 0.0% of statements [no tests to run]
?   	github.com/aimof/apitest/logger	[no test files]
ok  	github.com/aimof/apitest/parser/yamlparser	(cached)	coverage: 33.9% of statements

あらかた0、あっても低いという燦々たる結果となっています。

低いのには理由があります

メインの理由は、 初期開発中ゆえ破壊的変更を３回控えている ということです。結果、

Small Testのメンテナンスコストを上げたくない。
テストケースが最低限の正常系のみで網羅性が足りない。
変更の可能性が高いモックは作らない。

という方針を取ることとなり、加えて

別途Medium Testを用意してそちらに担保してもらっている要素が多い。

というのが現状です。

Medium Testについて

現状Medium Testでは、docker-composeを用いて、Mockサーバーを使ってテストをしています。

version: '3.7'

services:
  apitest:
    build: ../
    command: apitest
    depends_on:
      - server
    command: "apitest ../../test/bdd.yaml"
  server:
    build: server

serverサービスは、requestを受け取って指定されたリクエストに対応するレスポンスを返すモックです。

破壊的変更を控えているがゆえに行いたいテスト、やりたくないテスト、悩むテスト

さて、先程破壊的変更を３回控えていると書きましたが、その全てでドメイン層に変更が入ります。ドメインレイヤーってそんなに簡単に変更されるものだっけ？と思われるかもしれませんが、開発初期だから仕方ないと思ってやってます。

破壊的変更の内容について

apitestはRESTful API作成中のdeveloper向けに、めっちゃ小さいCI用イメージを提供することを目的としています。そのため追加機能は、

BDDライクな設定フォーマット＆jsonサポート
モックを一つ立てる機能
モックを複数立てる機能

です。

破壊的変更を控えているから行いたいテスト

破壊的変更によって破壊されない、あるいは修正の容易なSmall Test
- 具体的には、テスト仕様書を読み込むyamlparserや、jsonを比較するJsoncomparerなどです。
Medium Test
- 全体としてまともに動くことを捨てることはできません。

やりたくないテスト

破壊的変更でボロボロに成ることが予想され、修正も複雑なSmall Test
- 主に、モックを使ったドメインレイヤーのテスト。
- モック地獄をどうするか…

悩むテスト

Medium Testの実装方法として、

apitest自身が用意したモックを用いて自分自身をテストする
テスト専用モックを立てる

の二通りが考えられますがどちらがよいかを考え中です。

開発中に得られたこと

破壊的変更が大量に想定される状態でモックテストを作るのは負担が大きすぎる。
- しかし、後からテストを書きやすいように作らなければ後で泣く。
そういう際にSmall TestよりMedium Testを主軸に据えたほうがやりやすい。
- ただし、将来的なSmall Testの書きやすさには気を使う必要がある。
Medium Testを先に作るのはとても良さそう。
テストを書けるところは網羅性はさておき正常系テストくらいは書いておく。

以上

最近困っていること 〜モック地獄、破壊的変更とメンテナンス性〜