Goのテーブル駆動テストをわかりやすく書きたい

Goでテーブル駆動テストを書いていると、書いているときは「すげー読みやすくテスト書けてるぞ！」と思っていても、落ち着いてから見てみると「なんだこれ．．．訳がわからん．．．」となることがあると思います。(自分はよくあります。) この記事は、このようなことを解決するのに役立つtipsについてまとめています。主にテストケースについて焦点を当てています。 テストしやすいコード設計に興味がある方は や を参考にしてください。 はじめに この記事はパーソナライズGopher道場で学んだことを元に書いています。 そして、この記事で紹介するテーブル駆動テストの書き方は主観に基づいており、 あくまでテストの1つの書き方にすぎないです。 なので、「この書き方をしないとダメ！」というものではないので、みなさんの考え方やプロダクトに合わせて、柔軟にこの記事で紹介するtipsを取り入れていただけると幸いです。 結論

[takeshiketa]

ヘルパー関数で整えすぎると、構造書き換えたりしてる時とかリファクタリングの時もあるけど、テスト書き換えるの大変になるのよね。テスト書き換えがいちばん怖い作業だし後任者がスッとテストに手出し出来なくなる

[baronhorse]

1行にするとgofmtで詰められちゃって縦が揃わなくなるのがつらい。ヘルパは使いすぎると他人に読みづらくなってくので出来るだけ我慢してるな

[arx0balest]

普通にArrange-Act-Assert patternで書いてくれ。Functional Option Patternだの何だの、言語の貧弱さをクソコードで誤魔化すのがGopher wayなのか？Goはただでさえ読みづらいんだから、普通に書け。普通に。

[drunkennessimi]

test

[honma200]

CSVなりTSVでデータ吐いてパーサーで処理したらあかんの？あんまテストコードにデータ残したくないのよね。書くのはエクセルなりツールがあるし

[programmablekinoko]

エクセルでデシジョンテーブル埋めながら手動テストとどっちが辛いだろうか

[shag]

やりたい気持ちはよくわかるけど、テーブルテストって読みズラいよね。pytest とかでも結局避けてしまう。ヘルパー書けば書くほどヘルパーのバグに悩まされるしな。

[escape_artist]

わかりみが深い