テストをわざと壊して効率的に開発する

最近効率の良い開発の進め方について良く考えている

一番これ良いなと思える方法は、Breaking Driven Development
個人的な造語段階だが、破壊駆動
手法としては、変更を加えようとしている部分をわざとテストが落ちるように変えてすべてのテストを走らせて、その落ち方から次の方針を導き出す

これをやると

• 影響範囲の把握が最速でわかる
  • テストのカバレッジを知る
• デザインが洗練される
• 無駄なテストが減る
  • 足りないテストがわかる
  • 足りない制約(validation, authorizationなど)がわかる
  • JSのコード内のリスクの発見

（破壊するための）変更の具体的なパターンは次のようなものが思い浮かぶ

• factory/validation/relation/filterのオン・オフ
• 一時的なraiseを追加
• わざとtypoを混入
• 他

ただ一つ大きな欠点がある

全テストを走らすのに時間がかかる

全テストを走らすのに5分〜数十分かかっているものを数分に押さえるのが今一番に考えている課題

テストのFailuresの結果を見れば、その場その場で次どうしたら良いかはわかるのだけど、そのルール・パターンを明示的にまとめることはできていない
今後余裕があれば、具体的なコードと一緒にパターンを追求していきたい