概要
テストコードはプロダクトの持続可能な成長には不可欠で、私の所属する開発チームでは書くことが必須となっています。
しかし、書き方が人によって異なり、テストケースに過不足があったり、実装の仕方やレビューで悩んだりすることがありました。
そこで、テストコードの書き方のガイドラインを策定しました。現在では開発チーム全体で運用され、一定の効果を発揮しています。
本トークでは、このガイドラインの内容をもとに、テストコードを書くうえで最低限気をつけたいことについてお話します。
また、チーム全体で運用するための、策定のポイントについてもお話しする予定です。
テストコードの書き方を知りたい人はもちろん、テストコードレビューで悩んでいる人、チームで統一したコーディングルールを運用したい人にとって有益なものとなれば嬉しいです！
所感
テストコードに関しては、もちろん書いてはいるものの、チームとしてはまだまだ経験が足りず課題を感じていたポイントだったので、非常に参考になる話でした。
しかもちょうど、テストコードの構成について試行錯誤した後だったので、自分事として聞けました。
特に共感したのは、
作って終わりにしてはいけない
本当にその通りだと思うし、なんならそれを定着させる部分が1番、力がいりますよね・・・。
今後のテストコード運用において、とても参考になるお話でした。
スライド
受講メモ
何を検証したいかぱっと見でわからないテストコード
リファクタしたらテストが落ちた
ガイドラインあればいいんじゃない？
書籍から学んだテストの基本
なぜ実施する？
安全にリリースできる状態を継続的に維持する
バグを正しく検出できる
自信を持ってコード変更できる
実装の詳細ではなく振る舞いをテストする
振る舞いをテストする
実装の詳細
処理の具体的ななk毎
振る舞い
最終的な出力、返される結果
実装の詳細
モックを利用したテスト
実装の詳細を公開するとテストしづらい
振る舞いだけを公開する
モックの利用は最小限に
何をどうテストすればいいか
どこにどんなテストを書けばいいかわからに
ちょっとしたことで可読性は向上する
テストケース名
適切なアサーション
assertSameで大体できるか、continなど糸に合ったものを使う方が可読性がいい
ガイドライン
具体的な行動に結びつける
厳しくしすぎない
Redux style guideを参考に
項目ごとにpriorityがついている
ガイドラインではなくスタイルガイド
サンプルも用意
作って終わりにしてはいけない