新規開発をしながらカバレッジ0%の状態から70~80％までした話

1. テストコードをちゃんとした話
中村剛
09/01 2015

2. アジェンダ
①なぜテストコードが書けていなかったのか反省と分析
②現状を踏まえどうやって変えていったか
③まとめ

3. ①：忙しさという名の響きに負けた
全くのゼロからのスタートアップでやるべき事が溢れ、後
回しになり結局、十分な時間が取れなかった
フレームワークの比較見当、コーディング規約、テスト方
針、すべてが後手になり統一意識が取れず、各々が考え
る実装でくみ上げられていった。

4. ・同じようなメソッドが無駄に増える
・デグレが多発
・単純な凡ミスが増加
・ブラウザので手動テスト頼み、コストがドンドン膨らむ
この時テストコードの存在すらないので当然カバレッジ0%
よくあるダメなパターン

5. ②：決めを作ってとにかく頑張る
フレームワークの特性に合わせてある程度のコーディン
グ規約を決めた。
頑張ってリファクタした。
Jenkinsでユニットテストを定期的に実施するようにした
Jenkinsでテストの結果、カバレッジを視覚化した
Githubに移行してレビュー行程を導入した

6. ②：頑張った結果新たな問題も
ビジネスサイドからすると、エンジニアは頑張ってコード書
いてるけど、別に新機能や改善されてる機能のリリースが
少ないという不満
抱えている問題、先送りすればするほど傷が深くなるので
今その問題に対応してる為、新機能開発が遅れている旨
を説明
といってもリファクタ＋テストコードの実装だけでずっと人
員を避けないので、新規機能も実装＋ボーイスカウトポリ
シー（通りかかった道のゴミを拾うポリシー）で実装を進め
た

7. 大きな声で言えないけど軽く無視してやり続けた。
（時として必要）
100%のカバレッジは果てしなく遠いゴールなので70〜
80%した。Webサービスとして適正値と判断

8. ③：まとめ
・いくら時間が無くとも頑張りどころはあって、ココで踏ん
張りきれずに妥協すると向こう２年をこの問題に悩まされ
ると考えて頑張る
・色々考えて決めたら、途中問題が出てきても頑張りきる
ただし、結果間違った決めだった可能性もあるので時に
真摯に振返る
・自動化できる部分やツールで軽減できる事、定量的に
見える化は積極的に活用する