ajitofmのTDD回を聞いてTDDに入門した話

入門しましたので忘れないよう書き残しておきます。

きっかけ

新入社員の方にユニットテストの書き方を説明していく中で、自分自身に対して色々と思うことが出てきたのが始まりだったと思います。例えば以下のようなことを考えていました。

ユニットテストの目的って「バグの早期発見」てことでいいのだろうか
テストコードって、実装したあとの義務や責任で書くものなのか
実装工程からテスト工程までのタイムラグ（本当はみんな実装しながらテスト書いたりするよね？）

それから、ajitofmの第13回を見つけて聞いみて、通勤時の電車の中で何度も「いい話だなあ。」と相槌を打ったのを覚えています。

ajitofm 13: Test Driven Developmentajito.fm

結局はそれらがきっかけとなって、TDDを学んでみることにしました。

入門方法

使用した書籍はオーム社の「テスト駆動開発」です。

まずは一通り「付録C：テスト駆動開発の現在」を読んでみて、TDDを学ぶ意義について学びがあったので、何名かに声をかけて読書会をしていくことにしました。

あとは、「写経」をしながら、話の流れや考えたことメモするスタイルで進めていき、読書会での話題の種としました。コミットごとに感じたことを残したので、読書会で「このとき何考えてたっけ？？」とならず、議論が捗ったと思います。

f:id:sgyatto:20190202165650p:plain:w300

成果物

第I部 github.com
第II部 github.com

入門してみて

作業後の変化や感じたことを書いてみます。

ユニットテストの目的

まず、テストというものに対する捉え方が変わりました。それは、テストという作業を俯瞰する方法として「アジャイルテストの4象限」という考え方を知ったことと、実際に手を動かすことで、普段のユニットテストとは違う感覚を実感できたことが大きいです。具体的には、以下のような学びがありました。

テストは4つの軸（ビジネス面、技術面、チーム支援、製品批評）で捉えることで、目的や手法の異なる様々な領域に分けられること
ユニットテストは技術面・チーム支援といった領域のテストであり、バグの発見はその領域の目的の一部に過ぎないこと
TDDはプログラミングや設計を補助することを主要な目的としていること

つまり、ユニットテストには、バグを発見するという目的だけでなく「プログラミングや設計を補助する」ための使い方があるのだ、ということを本書は説明しているのです。まず付録Cを読んでから本編を読んでいくと、このことを理解しやすいのではないかと思います。

TDDという縛りプレイ

「テストを始めに書くこと≠TDD」であることは、本書を読んでいけばすぐにわかると思います。そして、以下の２つのシンプルな制約（縛り）を設けることによって、「プログラミングや設計を補助する」という効能が引き出されているのだということを実感するはずです。

自動化されたテストが失敗したときのみ、新しいコードを書く。

重複を除去する。

なぜそのような効能に繋がるのかというと、この制約の中でコードを書くことによって、現在の自分の立ち位置がわかりやすくなるから、というのが私が感じたことです。グリーンバーは、自分がどこまで実装できているかを示してくれるし、見落としについてはレッドバーが教えてくれます。手が止まったときでも、適切な大きさの問題を考え、コードで表現する場面だと気づかせてくれます。まるでセンサーのような作用と言いますか、自分の感覚をより鋭敏にしてくれているように感じました。これは、コードを書いていく中で感じる「不安」に対しても同様であると言えます。本書のまえがきには、