はじめに

TDD Boot Camp 2020 Onlineの講演・ライブコーディングを見て、テスト駆動開発とはこういうものなのかなという、僕が受け取り咀嚼したことを僕なりにまとめました。動画を見た方の簡単なおさらいやTDDに興味を持つきっかけになれば幸いです。
また、誤った認識等あるかもしれないので、まだ動画を見たことない方、TDDを知らない方はぜひ見てみてください。こんな開発手法があるのかと、衝撃を受けるかと思います。

また、テスト駆動開発のことを以後、英称である、TDD(Test Driven Development)と呼びます。

TDDのゴール

「動作するきれいなコード」です。非常にシンプルです。

TDDを進めるうえでの前提

動作する、と、きれい、の2つに分けて進める
設計し続ける
テストファースト

TDDの進め方

テストコードを書く(Red)　→　テストを最短で通す(Green)　→　リファクタリング

基本的に、このサイクルを回し続けます。

これを動作するときれいの2つの工程に分けると、

動作するコードを書く：テストコードを書く(Red)　→　テストを最短で通す(Green)
きれいなコードを書く：リファクタリング

動作するコードを書く

ここでのポイントは、テストを書く前に機能要件を洗い出したTODOリストを書くことです。
そうすることで頭の中が整理でき、取り組んでいる一つのことに集中できます。

TODOリストのように達成すべき機能要件を洗い出す
要件を一つ選ぶ
1. テスト容易性が高いものからが推奨
2. 優先順位が高いもの
テストを失敗させる（Red）
汚くてもテストが動くコードを書く（Green）

きれいなコードを書く

ここでのポイントは、テストは通るままでリファクタリングすることです。

一周した後

Red、Green、リファクタリングを繰り返す
テストの構造化
不要なテスト（三角測量のような）は消す

動画の中でt-wadaさんは、「テストは動く仕様書であれ」とおっしゃっています。
例えば、後に新しく参画した開発者がテストコード・実行結果を見ればある程度仕様が分かる状態を指します。
テストをクラスで分けて構造化をすることで、これを実現していました。

TDDのポイント

テストは動作する仕様書であれ

テストコードの構成は、準備、実行、検証

準備：使用するクラスのインスタンス化等
実行：テストする値の作成等
検証：assertEquals等

テストコードは検証(assertEquals)から書くのがおすすめ

単一のゴール（検証結果）からぶれなくなります。

「作る」よりも先に「使う」

これが私の中で結構革新的で、TDD以外にも適用できる考え方だと思いました。私は以下のように捉えました。

ここで言う「作る」とは、コードを書くこと。例えば、メソッドの中身を書くことなどが当たります。
「使う」とは、その書いたメソッドを使うことです。
ライブコーディングでは、先にこんなクラスのこんなメソッド使いたいな、とクラス.メソッドを先に書いてから、クイックFixでクラスと空メソッドを自動作成し、メソッドの中身を書いていました。

こうする理由は、プログラミングでは、開発者の書きやすいよりも、使いやすい（読みやすい・理解しやすい）事が大事だからです。
また、作りやすさと使いやすさは一緒になりにくい、と仰っていたのもポイントだと感じました。

One assertion per test

一つのテストに複数のassertionを入れると、失敗したassertionで止まってしまい、以降のテスト結果を見ることができないためです。
一つのテストに複数のassertionを入れないとテストとして成り立たないケースは除くようです。

不要なテストはそのテストを書いた本人が消すべきである

テストは不要かどうかは書いた本人にしかわからない
消さないと後々不良資産になる

最後に

作りやすさより使いやすさ、であったり、TODOリストで整理することなど、TDD以外でも使えそうな考え方が多くあり、非常に勉強になりました。