Kyoto.go remote #12 Reading uber-go/guide お題
事前に読めるひとは読んでおく(努力目標)
気になったこと/わからなかったこと/疑問に思ったこと
これはGoに特有の慣習かもしれない?
短くなり、テストケースも把握しやすい。追加も楽
gomockつかってるとTest Tables使いづらい uji.icon
細々とした指定が多くなって煩雑
最近はあまりgomock使わなくなった。外部サービスとかをmockするときには専用のモックを使う pinzolo.icon
give, wantという単語が好きyebis0942.icon
テストに使うデータはコードに書きたくない。fixtureとかにしたいluccafort.icon
コードに書くと型ベースの補完が効くのがうれしいuji.icon
期待するoutputをファイルに保存してテストに使うというパターンはある = golden file testingという一般的なパターン
want_output.goldenみたいなファイル名で保存する
Reactとかではsnapshot testとか言われてるパターンだと思うけど、もっと一般的なパターンがあったのかyebis0942.icon
Rubyでは1テストケース1テストメソッドという思想が主流っぽい
cf. Assertion Rouletteアンチパターン
「内部が隠蔽されている」みたいな意味らしい yebis0942.icon
なるほどluccafort.icon
確認したいこと
次回やりたいこと
アルゴリズム完走したらもう一度やりたいことを集計する
何もなければ次点の「GoFデザインパターンをGoで実装する」が採用されるという進め方でいこう、という話をした