Go Testing By Exampleの動画を見る会
Scrapboxへの参加リンク
開催概要
Slack
Google Meet: ConnpassにURLを記載しています
タイムテーブル
19:30 ~ 輪読開始
21:30 ~ 終了
今日見るもの
本日のメモ
目次をながめてから視聴する
1. Make it easy to add new test cases.
2. Use test coverage to find untested code.
uncover コマンドでテストプロファイルのカバーされていない行をだせる
3. Coverage is no substitute for thought.
4. Write exhaustive tests.
はやいアルゴリズムを書いたときに遅いけど確実に成功するアルゴリズムも一緒に書いてテストする
5. Separate test cases from test logic.
6. Look for special cases.
7. If you didn’t add a test, you didn’t fix the bug.
8. Not everything fits in a table.
9. Test cases can be in testdata files.
10. Compare against other implementations.
11. Make test failures readable.
12. If the answer can change, write code to update them.
テストを出力する
13. Use txtar for multi-file test cases.
^D があったら改行なしで終わってるファイルとして読み込むみたいな
14. Annotate existing formats to create testing mini-languages.
Ivy
Rob Pikeが作った電卓アプリ
testのための言語を作ると良い
15. Write parsers and printers to simplify tests.
いいテストヘルパーを作ればテストを書くたびに時短メリットを得られる
deps.devとは
16. Code quality is limited by test quality.
cmd/goのテスト
コマンドの一覧やファイルの内容を書いて実行して結果を確認するテスト
17. Scripts make good tests.
18. Try rsc.io/script for your own script-based test cases.
「すごいな」以上の感想がない
19. Improve your tests over time.
20. Aim for continuous deployment.
パースするの大変そうyebis0942.icon
そのためのrsc/script
tomato> APIのテストの書き方こんなやり方あるのまったく思いついてなかった
新しい武器をしった気分
テストコードはGoそのもので書かなくてもいいという説
rsc.io/script にこういうスクリプトのパーサーを書くのが楽にできるかもしれないので後でみる
ツールでできない部分を頑張ってなんとかしないといけないなら自分でスクリプトを実装するという考えに至るのかもしれない
Rubyで言語内DSLだ！！みたいな文化と意外と近い気がしてきた…yebis0942.icon
Rakefile
感想
Goでテストを書くことに対する前向きな諦めがある
巨大な構造体のテストの時に正しい値を埋めるための関数を作るということをしていたが、それをスクリプトで書くようにすると楽にできるかもしれない
github.com/rsc/scriptを読んでみる
cmd/go/internal/scriptからコピーしたもの
主な登場人物
Engine
State
scriptはどんなふうに実装されているのか
DefaultCmdを定義してる
mkdir の実装