テストでつまづきがちなのでどうすると良いか考える

症状

• あれコレ俺ハマってるじゃん，と気付いたとき，だいたいテスト書いている
• 実装する→テスト書く→ぜんぜん通らんなんで??→ヴァルハラ(永遠の戦い) というのがよくあるパターン
• 通らない原因
  • 別に準備しないといけないレコードがあった
    • DBがデカい1つのステートになっているので内部を想像しながらテスト書いてる
    • このレコードが無いと動かないワン！みたいなパターン
  • テストが正しくて，実装がぶっ壊れている
    • たまにあるけど気付かない
    • テストが正しくて実装が壊れてるけど通常の動作条件ではたまたま正しい挙動をしていて，機能追加で満を持して起爆することがある
  • テストも実装も狂っていて，設計段階から破綻している
    • ちょろそうだし実装サッとやってしまおうとして実はそこは死地だったパターン
      • 大東亜戦争
    • 結局どうしたらエエんや？という理解を疎かにするとここへ行く
• どんどん視野狭窄になっていく
  • 意識は「壊れている」テストを直すことに集中していく
    • 壊れてるんだから直すという欲求に理性が屈服する
  • だいたいこういう時は何やっても直らない
    • 単純な誤記の類ではなくなっている
  • 計画や作戦が破綻するので，どんどん行きあたりばったりになる
    • 通常の作戦フローでは選択肢が限られているので普通に判断して設計実装テストすればよい
    • ハマるとどうしたら良いか分からなくなる，脱出フローが無い
  • 自分が何やりたかったか忘れる
• 進捗ぜんぜん出ないので焦る
  • 焦るのでインデントやアラインメントを調整するなどの無意味な行動をする
  • 疲れてゴーヤの育て方みたいなページを見たりする
  • 自尊心が削れる

分析

• 準備せずに突入するとだいたい失敗するという学びがある
  • よく考えずに設計
  • 設計せずに実装
  • 何をテストすればよいか分からないのにテストを書く
• とはいえ「完全な」準備は不可能
  • ソフトウェアというのはそういうもの
  • 完全にコードベースとビジネスロジックを掌握していれば可能
    • ソフトウェアの行数にもよるが，大規模になると人間業ではない
• ここに「焦り」が加わる
  • 成果を出さなくては，進捗を出さなくては
  • 期日
  • パッとできると思っていた場合は特に急ぎがちになる
• 仮説と実験というモデルで物事を進めると良いかもしれない
  • 自然科学的メソッド
  • 実験やってみたけど全然違うやん，みたいな概念が発生するという点において自然科学とソフトウェア開発は似ている
  • 仮説を立てて，やってみて，うまくいかなそうであればツリーを一歩遡る
  • 「fooを実装すれば良さそう」というアクションだけの段階から，「fooであると仮定するとbarで達成できそう」という仮説込みの段階へ強化する
    • 前者は失敗した場合に止まるだけだが，後者は仮説が崩れたのかロジック自体が崩れたのかを考えられる
    • 仮説が無い場合は無限疲弊することになる

どうする

• なんとなくやってなんとなく終わるといった状態を避ける
• ちゃんと設計する
  • まあそれはそう
• ハマっていることに気付く
  • 当初の目的を見失い始める兆候に気付く
• 焦らない
  • ソフトウェア開発は農業みたいなところがある
    • 正しい方向に頑張らないと進捗しない
    • 焦ってもどうにもならない
    • 天候が悪ければ農作業ができないように，調子が悪ければ素朴にうまくいかない日もある
• 仮説を意識する