TODO

テスト容易性：高　重要度：高

数を文字列に変換する
- 1を渡すと文字列”1”を返す→仮実装
- 2を渡すと文字列”2”を返す→三角測量

テストは動作するドキュメントであってほしい
TDDではテストメソッド内で、検証・実行・準備の順番で書く
- 残酷な現実を突きつけられるのが早くなる
assertメソッドの実測値と期待値の引数の順番は最初に確認しておく
作る前に使う のがTDD
- 利用者側からどう使いたいかを考えて作っていく
- 使いやすいコードの方が作りやすいコードより大事
テストコードのテスト
- ミューテーションテスティング
  - 実行するのにコストがかかる
- 仮実装
  - まずレッドにしてテストコードのテストを行う
    - プロダクトコードの方でわざと間違ったことをしてレッドにする
  - 次にグリーンにする
    - 一番早くグリーンになる方法でコードを書く
      - ex) 期待される値をそのままベタに返す
リファクタリング
- テスト方法
  - 1つのメソッド内でアサートを増やす
    - アサーションルーレットというアンチパターン
    - どのアサートで失敗してるかどうかわかりにくい
    - 動作するドキュメントとして読みにくい
  - テストメソッドを増やす （おすすめ）
    - どこで失敗しているか自明
    - ワンアサーションパーテスト
    - ユニットテストではなくてエンドツーエンドテストの場合はコストが高いので1つのメソッド内で複数アサートも許容
- 三角測量
  - 三角測量を経由しないと仮実装を直しちゃダメということはない
  - テストの書き方に不安がなくなってくればそのまま実装でも大丈夫
    - 仮実装→実装という経由
テストコードのリファクタリング
- 重複の除去
- ツーアウト派
  - 2カ所重複
- スリーアウト派
  - 三カ所重複
  - 2だったらいいけど、三カ所は本格的に崩壊し始めている兆候とみなす
TDDのスキル
- 問題を小さく分割する
- テストコードと実装への不安と自信に応じて歩幅を調整する
  - テスト→仮実装→三角測量→実装
  - テスト→仮実装→実装
  - テスト→明白な実装
- テストの構造化とリファクタリング
インナークラスを使って仕様を明確にする
- テストの構造化とリファクタリング
- テスト仕様のツリー構造をクラスでも再現する
  - 仕様（5の倍数の時はBuzzに変換する）
    - 具体テスト（5を渡すと文字列Buzzを返す）
- 動作するドキュメントにする
- 必要最低限のテストだけ残す
  - 三角測量用のテストは削除しておく
テストの構造化とリファクタリング
- テストは不良資産になり得る
- テストのメンテナンスコストを考える

Poor Stack なウェブエンジニアの備忘録

@t_wada さんの #TDDBC 基調講演のメモ

TODO