なんでテストを書くの？

思ったとおりに動いていることを確認する

ちょっとずつ確認しながら進んでいくとつまらないバグがなくなる。

プロダクトコードの振る舞いのリスト

テストメソッド名で振る舞いを説明する。
テストコードなのでウソの(疑わしい)ドキュメントとならない。
(--testdoxオプション)

実際に動かすことができるサンプル

初めて見る処理に修正を加えないといけなくなった時、
とりあえず動かして何が起こるのか見てみたかったりしない？

手軽に再現可能な動作確認の手段

あるバッチ処理を動かすために・・・
マスターテーブルにデータを入れて、別のバッチでランキングデータを作って(1時間)、ブログの管理ツールから新規の記事を公開して、YAMLファイルをアップロードして、キャッシュが切れるまで1時間待って、ブラウザで現在の記事リストを確認して、バッチプログラムを実行して、記事リストに追加された記事を確認！

動作確認のたびにこれが必要だとしたら・・・？

• ユニットテストでの解決
  • モックによって修正対象コードの動作確認に注力
• システムレベルのテストの自動化での解決
  • 無駄な待ち時間無しに誰もが実行できるシステムレベルの動作確認手順の作成
    • 最初からこれを意識した作りで準備するのが重要
    • あとからやろうとするとかなり辛い
    • 最初からテストを作っていくことが重要
    • 最初からテストを作っていくことが重要

設計に関するスキルの向上

実際のプロダクトコードでは、簡単にテストを書けるケースはあまり多くない。

• シンプルにテストが可能な単位に分割したり
• そもそもテストが可能なように外部依存を切り出したり

といったことをしていくことでスキルの向上につながる。