はじめに

TDD Boot Camp 2020 Online #1 基調講演/ライブコーディングのアーカイブ動画
を見て感じたことを書きます。
https://www.youtube.com/watch?v=Q-FJ3XmFlT8&t=1730s

感じたこと。とてもシンプルに

- テストコードは多すぎるとメンテナンスコストが上がる
- テストコードは仕様書のように書く

テスト駆動開発のゴール

『動作するきれいなコードを書く』こと

テスト駆動開発とは

天才プログラマーじゃ無い普通のプログラマーが、
自信を持って着実に『動作するきれいなコード』に向かっていくためのテクニック
※天才プログラマーはテスト駆動開発とかしなくても、動作するきれいなコードが書ける

どうやって動作するきれいなコードを書くか？

分割統治する。
まず、動作するコードときれいなコードに分けて対処する。

TDDはサイクルである

以下の7つの繰り返しになっている
1. 次の目標を考える
2. その目標を示すテストを書く
3. そのテストを実行して失敗させる（Red）
4. 目的のコードを書く
5. 2で書いたテストを成功させる（Green）
6. テストが通るままでリファクタリングを行う（Refactor）
7. 1~6を繰り返す

テスト容易性が高いものから最初にやる

最初にTODOリストを作ったら、
その中から1つを選んでテストを書く。
一気にやらない。

TDDでのリファクタリングの定義

成功しているテストが成功しているままで、コードをきれいにしていくこと。
ケントベックは、ファウラーが『外部からみた振る舞い』と言ったのを『成功しているテストが成功しているまま』と言い換えた。
※リファクタリングの著者ファウラーは以下のように定義している。
外部から見た振る舞いが変わらないもので、内部をきれいにしていくこと

演習：FizzBuzz問題

お題：

1から100までの数をプリントするプログラムを書け。
ただし3の倍数の時は数の代わりに『Fizz』と、
5の倍数の時は『Buzz』とプリントし、
3と5両方の倍数の場合には『FizzBuzz』とプリントすること。

要素に分解する

※要素に分解するのは技術が必要。

TODOリスト
=============================
テスト容易性：高、重要度：高
- [ ] 数を文字列に変換する
- [ ] 1を渡すと文字列1を返す → 仮実装
- [ ] 2を渡すと文字列2を返す → 三角測量
- [ ] 3の倍数のときは数の代わりに『Fizz』に変換する
- [ ] 3を渡すと文字列『Fizz』を返す → 仮実装 → 実装
- [ ] 5の倍数のときは数の代わりに『Buzz』に変換する
- [ ] 5を渡すと文字列『Buzz』を返す → 明白な実装
- [ ] 3と5両方の倍数のときは数の代わりに『FizzBuzz』に変換する
テスト容易性：低、重要度：低
- [ ] 1からnまで
- [ ] 1から100まで
- [ ] プリントする

テストには4フェーズある

準備、実行、検証、後片付け
後片付けはガベージコレクターがやってくれる場合もある。
テスト駆動開発では、検証、実行、準備の順番で書いていく。
検証：assert
例：assertEquals(expected, actual);

assertを縦に並べるのはアンチパターン

アサーションルーレットという。
テストコードを見れば仕様がわかるようにしたい。
テストコードは動作するドキュメントにしないといけない

テストコードの量は多ければいいわけじゃない

3年後の後輩が見た時に、最低限の量で仕様を把握できるように書きたい
テストコードを減らすのは本人しかできない
これをしないとテストのメンテナンスコストが上がる