2021-11-17

GoMockテスト辛い問題とかDDDって何それうまいの?とか

GoMockってのはGo言語ライブラリで、依存するinterfaceテストモックに置き換えてくれる。

それで、テスト中のモックの期待される振る舞い等を簡単定義できるのだ。

期待される振る舞いってのは、モックメソッド呼び出しやその引数とかだな。

期待される呼び出しが無かったり、引数が違ったりするとテストが失敗してくれる。

他に、メソッド戻り値副作用記述できる。

非同期処理のテストだとよく、wg.Done()をモックにさせたりする。

正直、これまで書けなかったテストがモリモリ書けて楽しい

けれどそのうち辛くなってくる。

まり、たくさんのinterface依存するサービスオブジェクトメソッドテストしようとすると、たくさんのモックのたくさんのメソッド呼び出しの全部の期待される振る舞いを書かないといけない。

モックメソッド戻り値によってサービスオブジェクトメソッド内の挙動が変わる。

すると連鎖的に、メソッド内で続いて呼ばれるモックに期待される挙動も、変わる。

依存interfaceが増えるとこの場合けが指数関数的に増える。

当然だ。

Go言語にはテーブルリブテストっていう、テストケースは配列簡単にまとめられると良い、という慣習・哲学がある。

しかし俺のサービスオブジェクトテストケースが肥大化複雑化しすぎてしまったようだ。

モックの期待される挙動を細かくケースに分類して配列にするのは恐ろしく辛い作業だ。

やりたくない。

どうしてこうなった

どうしてこうなったかは明らかだ。

サービスオブジェクトが巨大すぎるのだ。

ノシリックで巨大で複雑なものは凡人には扱えないからやめとけ、と偉い人は言う。

そうだなモノシリックは辛い。DDDかにすればいいんだろ?

やったよ(見様見真似で)。

モックでこれまでできなかったテストが書けるのはいいね

でもじつはここはまだ山麓だったのです。

サービスオブジェクトが巨大なモノリス化してしまったのです。

分け入っても分け入っても青い山。

おれはどこに行けばいいのだ。

参考文献

https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month

あとどこかにDDD100本ノックとかないかな。

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん