unittest

unit testをちゃんとした話

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide