id:kyon_mm さんのテストファースト、自動テストを導入するという事について(@社内勉強会) に感銘を受けたのと、社内でユニットテストの機運が出てきたので開催しました
自分のスライド
kyon_mmさんのスライドで口頭補足したカンペ
- 14: ミカドメソッド
- 15: まずは挑戦する
- 「(知ってるけど今回はテストファーストに向いてないから)やらない」「(そもそも知らないから)やらない」というのは全くの別物
- 選択肢を増やして損はない
- 17: Second Step: 綺麗なテストコードを心がける
- テストコードもプロダクトコード同様会社の資産であり保守されるものなので、テストコードも読みやすさやリファクタリングすべき
- 22: ユニットテスト:中身が分かる前提で(内側から)テストを行うのでホワイトボックステスト
- 23: インテグレーションテスト:中身が分からない前提で(外側から)テストを行うのでブラックボックステスト
社内からきたミカドメソットについての マサカリ 補足
- 影響範囲とか何も考えずに変更してみる
- コケたところ1をメモる
- コケたところ2をメモる
- revert する
- コレがミカドメソッドの肝
- 3 を綺麗に解決して *1リリースする
- 2 を綺麗に解決してリリースする
- 1 の影響範囲は全部両対応するよう修正済みなのでビッグバンマージにならない!幸せ!
Q&A
Q. テストコードとプロダクトコードの各時間の割合(さすがに半々って多いよね?)
そうでもないよw
自分の場合テストは設計も兼ねてるので、考える時間も含めるとテスト8割くらいになることもある。
Q. 今のプロジェクトのspecが動かない
全部消せばいいんじゃないかな(経験者談w)
直す方が時間かかるようであれば全部消して最初からやり直した方が早い
Q. 参考書籍(ミカドメソットは知らなかったのでどういう本を読めばいいのか知りたい)
スライドの最後に追記
追伸
テストチョットデキルTシャツはこちらより買えます
sue445 の【ワタシハ テスト チョットデキル】Tシャツ ∞ SUZURI
*1:cherry-pick