golangのtestは自由度が高すぎる

golang は標準で testing というパッケージを持っていて、テストコードを書いたり、テストコードは実行ファイルに含めないようになっていたりとテスト用のしくみがある。

それはよいのだが、自由度が高すぎると思う。ファイルや関数の決まり事以外は t.Errorf()を通ればエラー、というだけのルールだけなのでどのようにでも書けてしまう。私はテストする関数と、あとは結果が正常系だったりエラーのxxだったりみたいな感じでテスト関数を分けて書いたりしていたが、境界値テストみたいな場合は構造体で INPUT と期待する OUTPUT の組を作った配列を for でぐるぐる回したりして、今ひとつ統一性がなかった。

 

go.dev の wiki には TableDrivenTests という項目があった。さっき最後に書いた構造体でテストデータと結果を作って流すような書き方がこれのようだ。

TableDrivenTests - The Go Programming Language
https://go.dev/wiki/TableDrivenTests

この方式だけでテストが書けるならば、テスト対象の関数とテスト関数が同じ数だけ並ぶので、わかりやすいと思う。
ただねー、INPUT と OUTPUT 以外に「前提条件」もあることが多いではないか。あれを構造体だけで表すのが難しいこともあると思うのだよ。
と思ったが、関数分けして書いたとしても前提条件を実装しないといけないことに変わりは無いので、それを「前提条件1」「前提条件2」みたいな INPUT にして、それぞれを if 文で分岐してしまえば同じことなのか。あるいは構造体に func なメンバーを持ってしまえば良いのか。

 

などなど、go.dev に書いてある方式を使うことにしたとしてもまだ自由度が高いと思う。もうちょっと縛ってくれないだろうか。
こういうときはフレームワークだと思う。例えば JavaScript だとほぼ jest がデファクトスタンダードになっていると思うが、そういうやつ。

自分で探す気力が無かったので、記事を探した。

• https://techblog.kayac.com/2022-group-calendar-go-test
• https://medium.com/@dees3g/finding-your-best-go-testing-framework-5b5c6b299bd3
• https://speedscale.com/blog/golang-testing-frameworks-for-every-type-of-test/

 testify がよく出てくるようだけど、デファクトスタンダードとまではいかないというところだろうか。

assert があるとテストの比較する部分の書き方が統一される。比較しているどちらが期待値でどちらが実際の値かということに頭を使いたくないのだ。mock はどのくらい使いやすいのかによるが、自分でモックのしくみを考えたくないのであるなら利用したい。

と、今回は紹介だけになった。気が向いたら次回試してみようと思うが、普通に使うなら本家のサンプルを見た方がわかりやすいだろう。