はじめに
TDD Boot Camp 2020 Onlineの講演・ライブコーディングを見て、テスト駆動開発とはこういうものなのかなという、僕が受け取り咀嚼したことを僕なりにまとめました。動画を見た方の簡単なおさらいやTDDに興味を持つきっかけになれば幸いです。
また、誤った認識等あるかもしれないので、まだ動画を見たことない方、TDDを知らない方はぜひ見てみてください。こんな開発手法があるのかと、衝撃を受けるかと思います。
また、テスト駆動開発のことを以後、英称である、TDD(Test Driven Development)と呼びます。
TDDのゴール
「動作するきれいなコード」です。非常にシンプルです。
TDDを進めるうえでの前提
- 動作する、と、きれい、の2つに分けて進める
- 設計し続ける
- テストファースト
TDDの進め方
テストコードを書く(Red) → テストを最短で通す(Green) → リファクタリング
基本的に、このサイクルを回し続けます。
これを動作するときれいの2つの工程に分けると、
動作するコードを書く：テストコードを書く(Red) → テストを最短で通す(Green)
きれいなコードを書く：リファクタリング
動作するコードを書く
ここでのポイントは、テストを書く前に機能要件を洗い出したTODOリストを書くことです。
そうすることで頭の中が整理でき、取り組んでいる一つのことに集中できます。
- TODOリストのように達成すべき機能要件を洗い出す
- 要件を一つ選ぶ
- テスト容易性が高いものからが推奨
- 優先順位が高いもの
- テストを失敗させる（Red）
- 汚くてもテストが動くコードを書く（Green）
きれいなコードを書く
ここでのポイントは、テストは通るままでリファクタリングすることです。
一周した後
- Red、Green、リファクタリングを繰り返す
- テストの構造化
- 不要なテスト（三角測量のような）は消す
動画の中でt-wadaさんは、「テストは動く仕様書であれ」とおっしゃっています。
例えば、後に新しく参画した開発者がテストコード・実行結果を見ればある程度仕様が分かる状態を指します。
テストをクラスで分けて構造化をすることで、これを実現していました。
TDDのポイント
テストは動作する仕様書であれ
テストコードの構成は、準備、実行、検証
- 準備：使用するクラスのインスタンス化等
- 実行：テストする値の作成等
- 検証：assertEquals等
テストコードは検証(assertEquals)から書くのがおすすめ
単一のゴール（検証結果）からぶれなくなります。
「作る」よりも先に「使う」
これが私の中で結構革新的で、TDD以外にも適用できる考え方だと思いました。私は以下のように捉えました。
ここで言う「作る」とは、コードを書くこと。例えば、メソッドの中身を書くことなどが当たります。
「使う」とは、その書いたメソッドを使うことです。
ライブコーディングでは、先にこんなクラスのこんなメソッド使いたいな、とクラス.メソッドを先に書いてから、クイックFixでクラスと空メソッドを自動作成し、メソッドの中身を書いていました。
こうする理由は、プログラミングでは、開発者の書きやすいよりも、使いやすい（読みやすい・理解しやすい）事が大事だからです。
また、作りやすさと使いやすさは一緒になりにくい、と仰っていたのもポイントだと感じました。
One assertion per test
一つのテストに複数のassertionを入れると、失敗したassertionで止まってしまい、以降のテスト結果を見ることができないためです。
一つのテストに複数のassertionを入れないとテストとして成り立たないケースは除くようです。
不要なテストはそのテストを書いた本人が消すべきである
- テストは不要かどうかは書いた本人にしかわからない
- 消さないと後々不良資産になる
最後に
作りやすさより使いやすさ、であったり、TODOリストで整理することなど、TDD以外でも使えそうな考え方が多くあり、非常に勉強になりました。