先日、テスト駆動開発(TDD)オンライン勉強会 #1 に参加しました。今回はオンライン開催。簡単に所感をまとめます。
所感
ライブコーディングが2本ありました。TDD のセッションで FizzBuzz 以外の題材が見れたのはとても参考になりました。途中でググったり普段の生々しい感じのコーディング風景が見れてなかなか面白かったです。
FizzBuzz の TDD と言えば、de:code 2017 で t_wada さんが公演されていた動画がとてもわかりやすいです。今回、コメント欄にもいらっしゃって大変学びがありました。
TDD や自動テストの特徴や課題について、感覚的になんとなく理解はしているつもりでも、きちんと言葉で説明されるとなるほどと思うところがあります。特に自動テストと TDD の違いやカバレッジのあたりの話とか。
以前、TDD (モドキ) を実践してみましたが、リファクタリングや機能追加に対して安心感があって、やはりそのあたりは TDD の大きなメリットかなと思います。最近はテストがほぼないレガシーな環境にいるので、まずは自動テストから取り組まなければ...。
TDD とは関係ないけど、JUnit の diff のビューが便利そう。Eclipse でも使えるんだろうか。あと、懇親会は参加してないけど、spatial.chat が面白そう。Vue.js が使われてるっぽい。
以下、メモから抜粋。
ライブコーディングで体感するTDD基礎
https://youtu.be/UhHdnLTxOjEyoutu.be
- TDDはDDDとも相性がよい
- Red-Green-Refactor
- TDDは開発スタイルであり教義ではない
- 手段が目的になってはいけない
- TDDだけで十分に品質保証できるわけではない
- 必要なければリファクタリングはスキップしてよい
- ステップを細かくすると過剰な設計を防げる
- Red ⇒ Green までに時間がかかるときは過剰な設計を疑う☆
- 差分が大きいとテストコード外の不具合を埋め込んでいるかも
- フィードバックサイクルの短さが大事
@ParameterizedTest,@CsvSource,@MethodSource(JUnit)- ループで回すと各テストを展開してくれない
- アサーションルーレット
- Parameterized Test
- 期待値ごとに分けるかどうかはテスト対象の性質とテストコードの可読性による
- テストコードから仕様が読み取れるか
- 同値分割における同値クラスを増やす場合に楽？☆
- リファクタリングしたテストコードがきちんと動作するかプロダクションコードをわざと壊してテストが落ちることを確認することも大事 (テストのテスト)
- TDDと自動テストは解決したい課題が異なる☆
- 自動テスト
- TDD
- 十分なテストが書かれやすい
- カバレッジは「足りないこと」は不足はわかるが「十分であること」の根拠には使えない☆
- テストが書きにくい設計であることに気付く
- 自然と高凝集/低結合なクラスを書くようになる☆
- 外部APIはモックにする
- Dockerで代用するのもあり？
- Red からなかなか Green にならないと正しい方向に進んでいるか分からない
- Red-Green-Refactorの うち Refactor のところで設計する☆
- Red-Green のうちは汚くてもいいからとりあえず通す
- ToDoリスト
- テストしやすくするためにメソッドを括り出す
- テスト観点が明確になる
- 1テストメソッドにまとめるとテストのバリエーションを増やしにくい
- カバレッジが100%でもアサーションが十分かどうかは分からない☆
- テストから書いた方が抜けにくい
- 自動テストはMust/TDDはWant
- TDDは開発の進め方なので強制しにくい
- テストコードの保守コスト
- 自動テストの問題 ⇒ 解決するにはテストを書くスキルが必要
- TDDだけでは品質は担保できない
- テスト戦略の問題 ⇒ UT以外に全体としてどうするか
- テスト実装工数
- 自動テストの問題 ⇒ 長期的に回帰テストのコスト削減になるかで判断
- TDDの問題の多くは自動テストの問題であることが多い
