ひとつずつ、着実に

今回は課題こそ決して難しいものではないが、過程において得るものが多かった。
テストの存在はスタックトレースを考えた頃から自分の中で重要度を増していった。

原因が分かりにくいデバッグはだるい。
この世から抹殺したい。

テスト。
テストコードとテスト対象（実装したい機能）を平行して書く。
CreateMaze()を書くためにCreateMazeTest()を書いて、場合によってはCreateMazeTest::DrawMaze()まで書く。
視覚的に一瞬で結果が分かればモチベーションも高まる。
CreateMaze()の仕様は実はMazeクラスとMazeTest()を書いたときに大体決まる。

ただあんまりテストコードが肥大化するとテストコードのテストコードが必要になる気がする。
このあたりはまだ分からない。

作る前に完全な仕様を思い浮かべるのは困難だ。
まず手を動かしながら考える方がいい。
何を出力したいか、どんな機能が必要かという事をテストコードから考え、仕様を逆算することも出来る。

機能と機能を組み合わせたときに足りない機能が見えてくることもある。
そのとき追加した機能をすぐにテストしたい。
単体テストのコードがあれば、もう片方の機能が出来上がってなくてもすぐテストできる。

テストが前提になると１つの課題が小さくなる。
なぜなら複雑なテストは組み合わせの数だけテストが膨大になり、面倒だからだ。
小さな課題は解決しやすい。
大きな課題を小さな課題に分割する指標としてテストの存在は大きい。

コード読解は面倒だ。
意味は分かっても、完全に正しいかどうかは分からない。
人間の目で判断する作業は非常に神経をすり減らすものだ。
時間が経ってブラックボックス化してしまった機能も、テストコードさえあれば「とりあえず動いている」ことはすぐに確認できる。

テストコードを書くことはいい事ずくめだ。