発端

https://journal.lampetty.net/entry/moq-instead-of-gomock

https://twitter.com/mpyw/status/1617929996353564672

モックとスタブの違い

https://qiita.com/hirohero/items/3ab63a1cdbe32bbeadf1

↑に書いてある図が全て。

moq の公式マニュアルに書かれている使い方

https://github.com/matryer/moq

func TestCompleteSignup(t *testing.T) {
	var sentTo string

	mockedEmailSender = &EmailSenderMock{
		SendFunc: func(to, subject, body string) error {
			sentTo = to // ← 引数アサーション
			return nil
		},
	}

	CompleteSignUp("me@email.com", mockedEmailSender)

	callsToSend := len(mockedEmailSender.SendCalls())
	if callsToSend != 1 {
		t.Errorf("Send was called %d times", callsToSend)
	}

	// ↓引数アサーション
	if sentTo != "me@email.com" {
		t.Errorf("unexpected recipient: %s", sentTo)
	}
}

モックは受け取る引数を検証する ためのものであり，何を返すかはテスト側で副次的に決めるだけなので本質はそっちじゃない。なので上記の 引数アサーション を放棄したものはモックと呼んではならない。それはただのスタブだ。

もとのブログで主張されている使い方

githubClient := &github.ClientMock{
    ListBranchesFunc: func(ctx context.Context, owner string, repo string) ([]string, error) {
        return []string{"main", "feature/xyz"}, nil // ← 引数アサーションを書いていない
    },
}
s := Service{githubClient: githubClient}
out := new(bytes.Buffer)
if err := s.PrintBranches(context.Background(), out, "oinume", "playground-go"); err != nil {
    t.Fatal(err)
}
fmt.Printf("out = %v\n", out.String())
// ↓引数アサーションも呼び出し回数アサーションも書いていない

はっきり申し上げる。これはスタブだ。ゆえに，モックライブラリとしてこれら 2 つを比較するなら不公平として見ていいと思う。

defer ctrl.Finish()

これに関しても， 呼出回数アサーションを任せるタイミングを「テスト関数を抜けるとき」で gomock に任せるための記述 であり，一方の moq は明示的に .SendCalls() の返り値のアサーションを書く必要がある。むしろ手抜きできてラクなのは gomock のほうなのだ。

端的に言うなら

• gomock は型安全なモック処理を行うための正統派ライブラリで，スタブのためにも使える
• moq はスタブを手軽に作るために特化したライブラリで，モック機能はおまけ

gomock が any で受けている部分があるから型安全じゃないとブログでは主張されているが，これは意図的なデザインである。引数で受けたものを検証するために Matcher という仕組みが用意されている。直接値を受け取る場合と， Matcher でラップしたものを受け取る場合があるのだ。直接受けた値 v は，内部的に gomock.Eq(v) としてラップされ，全て Matcher に統一される。 以下の 2 つの記述は等価だ。

client.EXPECT().FetchUser(1)

client.EXPECT().FetchUser(gomock.Eq(1))

値の完全一致を調べるgomock.Eq() は非常によく使われる Matcher であるため，そのまま値を渡せるようになっているのだ。こういう仕様なら型宣言が any になるのはやむを得ないし，むしろ型安全なほうに倒すなら型制約は Matcher のみになるべきだ。 ここで int を要求してしまうと，値の完全一致以外の比較ができなくなってしまい，柔軟性に欠ける。

一方で，期待を定義する client.EXPECT().FetchUser() ではなく， 実際に動かしてもらう client.FetchUser() のほうは本来の型通りになっている。何も問題はなく，むしろ gomock は静的なコード生成により，型安全性を重視したライブラリなのだ。

moq でモック的に使いたい

マニュアルにも書かれている通り，面倒なコードを書く必要がある。全く Easy じゃなく，むしろ Simple を追求した形だ。

gomock でスタブ的に使いたい

どうやるんだろう？と思った方がおられるかもしれないが， gomock はこれにもちゃんと対応してくれる。 EXPECT() に続けて期待を書いたあと，以下のように繋げられる。

• Return() は指定された値を返す
• Do() は何か任意のコードを実行する
• DoAndReturn() は何か任意のコードを実行してその結果を返す

もとのブログにある moq によるスタブの例を gomock の例に置き換えてみる。

githubClient := &github.NewMockClient()
githubClient
    EXPECT().
    ListBranches(gomock.Any(), gomock.Any(), gomock.Any()).
    Return([]string{"main", "feature/xyz"}, nil)

githubClient := &github.NewMockClient()
githubClient
    EXPECT().
    ListBranches(gomock.Any(), gomock.Any(), gomock.Any()).
    DoAndReturn(func (ctx context.Context, owner string, repo string) ([]string, error) {
        return []string{"main", "feature/xyz"}, nil
    })

ポイント

• スタブを作るだけであれば，引数のところは全て gomock.Any() による Matcher でよい。検証の必要がないからだ。
• シンプルに値を返すだけでよければ Return() でよい。
• 何か動かした結果の値を返したければ DoAndReturn() を使う。こちらを使えば， moq と同じことができるはず。

浅慮で恐縮ですが、書籍 テスト駆動開発 には次のような記載があります。

語彙の整理により、xUTP 出版後は「広義の Mock Object」と「狭義の Mock Object」を分けて議論できるようになり、後続のモックライブラリの機能名も明確になりました。
引用：テスト駆動開発 付録 C p290

広義の Mock Object は Test Double を指すので、もしかすると moq は Test Double をモックとして捉えていてモックに対する解釈のズレが生じているのかもなと読んでいて感じました。

以下は参考にした記事です。

• なぜJestのmockライブラリに混乱してしまうのか？ - Qiita
• xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中