GoMockってのはGo言語のライブラリで、依存するinterfaceをテスト用モックに置き換えてくれる。
それで、テスト中のモックの期待される振る舞い等を簡単に定義できるのだ。
期待される振る舞いってのは、モックのメソッド呼び出しやその引数とかだな。
期待される呼び出しが無かったり、引数が違ったりするとテストが失敗してくれる。
非同期処理のテストだとよく、wg.Done()をモックにさせたりする。
けれどそのうち辛くなってくる。
つまり、たくさんのinterfaceに依存するサービスオブジェクトのメソッドをテストしようとすると、たくさんのモックのたくさんのメソッド呼び出しの全部の期待される振る舞いを書かないといけない。
モックのメソッドの戻り値によってサービスオブジェクトのメソッド内の挙動が変わる。
すると連鎖的に、メソッド内で続いて呼ばれるモックに期待される挙動も、変わる。
依存interfaceが増えるとこの場合分けが指数関数的に増える。
当然だ。
Go言語にはテーブルドリブンテストっていう、テストケースは配列に簡単にまとめられると良い、という慣習・哲学がある。
しかし俺のサービスオブジェクトはテストケースが肥大化複雑化しすぎてしまったようだ。
モックの期待される挙動を細かくケースに分類して配列にするのは恐ろしく辛い作業だ。
やりたくない。
どうしてこうなったかは明らかだ。
モノシリックで巨大で複雑なものは凡人には扱えないからやめとけ、と偉い人は言う。
やったよ(見様見真似で)。
でもじつはここはまだ山麓だったのです。
分け入っても分け入っても青い山。
おれはどこに行けばいいのだ。
参考文献
https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month