こんにちは。ADWAYS DEEEでリードアプリケーションエンジニアをしているDJです。
最近スタンドライトを買いました。今までシーリングライトのみしかなく、色温度も変えられなかった我が家に革命が起きました。時刻に応じて自動で明るさや色温度を変えることで、自然に眠くなってスムーズに入眠できます。
さて、私が所属するチームではTDD（テスト駆動開発）を活用して開発しているのですが、このTDDをより良いものとするために「テスト駆動開発」（Kent Beck著）の輪読会を行いました。
本記事では、その輪読会で得られた知見を共有したいと思います。
本記事は、すでにTDDについて基本的な知識をお持ちの方や、実際にTDDを行っている方を対象としています。
TDDの基本について知りたいという方は、チームのメンバーが書いた以下の記事をご覧ください。
輪読会の進め方
週に1回2時間程度、毎週2~6章を事前に読み、気になった点や疑問点を付箋に書き出して議論する形式で進めました。
- 青：感想
- 黄：疑問
- 灰：コメント・議論のログ
「テスト駆動開発」を読んでの感想
輪読会を通してまず感じたのは、「TDDのルールは意外と緩い」ということでした。
私が過去に学んだTDDは、テストを満たす最小限の実装が基本であり、厳格なイメージがありました。
しかし、本書ではTDDのルールは以下の2つしかありませんでした。
- 自動化されたコードが失敗したときのみ、新しいコードを書く。
- 重複を排除する。
最小限の実装を行うか、他のケースも考慮した実装を行うか。 本書では、この実装の歩幅は自分の自信の度合いによって調整して良い、と書かれていました。
自信がない場合は厳密に進め、自信がある場合はきれいでシンプルな実装を最初から行っても良い。
この「歩幅の調整」こそが重要であるという著者のメッセージは、チームにとって新鮮な発見でした。
得られた学び / TDDの実践的な考え方・プラクティス
本書を読む中で学びになった考え方やプラクティスについていくつかご紹介します。
「明白な実装」 「三角測量」
本書では、明白な実装と三角測量の2つの手法が紹介されました。 明白な実装とは、テストを書いた後、そのテストを通すためのシンプルで明確な解決策が思いついている場合、その通りに実装する手法です。 一方、三角測量は、まず1つのテストを書き、それを満たす最小限の実装を行います。その後、別の側面をカバーする新しいテストを書き、それらのテストを満たすよう実装する手法です。
これらの手法は状況に応じて使い分けることが重要であり、実装に対して十分な自信がある場合は明白な実装を行い、自信が持てない場合は三角測量を行うと述べられていました。
これまで私たちのチームでは、必ず三角測量を行うというスタンスでTDDを行っていました。最初にTDDを学んだ時から三角測量はmustであるという認識だったので、この考え方はかなり意外でした。
「細かなステップを窮屈に感じるならば、歩幅を大きくする。不安を感じるならば、歩幅を小さくする」
クラスの削除やインターフェースの変更など、大きな変更を一気にやるか少しずつやるか悩むことが度々あります。
本書では、自信があるなら大胆に大きな歩幅で進めても良いし、自信がないなら数分で終わるような小さな作業に分割しても良いと述べられていました。
この歩幅の調整に関するプラクティスは本書の中で何度も登場します。
前項の明白な実装と三角測量の使い分けも歩幅の調整ですね。
自身の自信に合わせて歩幅を自由に調整できるようになることが、TDDをマスターするうえで非常に重要です。
「不安が退屈に変わるまでテストを書く」
TDDを学んだ当初から「テストはどこまで書けば良いのか」を悩み続けていました。想定され得る全てのケースを網羅するべきか。網羅しようとするとテストが膨大になってしまう。でもこのケースはカバーしておきたいかも...。
このような悩みに対し、本書では「不安が退屈に変わるまでテストを書く」と書かれていました。
自信がない箇所ほどこれで大丈夫であると自信が持てるまでテストを書く、という意識を持つことが大事です。 （そのくらいやらないと観点が抜けてバグに繋がる可能性が高い） また、不安に思ったその場で対応できずとも、せめてTODOリストに入れておくと良さそうです。
「割り込みにさらに割り込むことはしない」
テストや実装を繰り返していると、ふと別のタスクや修正点が頭に浮かぶことがあります。
本書では、そのような割り込みは1回まで許容するが、割り込みにさらに割り込むことはしない、と書かれていました。
割り込みに割り込むことはしないという考え方は、プログラミング以外の普段の業務でも使える良い指針になりました。 また、一旦後回しにしたものはTODOリストやコメントとして残しておくと、可視化されて後々忘れてしまうことが少なくなって良いです。
「アジャイルテストの4象限」
アジャイルテストの4象限という考え方も印象的でした。
※ ATDD: Application Test Driven Development（アプリケーションレベルのテスト駆動開発）
または Acceptance Test Driven Development（受け入れテスト駆動開発）
※ ATDP: Acceptance Test Driven Planing（受け入れテスト駆動プランニング）
※ BDD: Behavior Driven Development（ふるまい駆動開発）
この図はソフトウェアテストにおいて各テストがどのような位置にいるのかを示しており、TDDはチームを支援する技術的なテストであることがわかります。
この図から、TDDだけではソフトウェア全体の品質を保証できず、受け入れテストや負荷テストなども重要であるということを改めて認識しました。
TDDの本質
「テスト駆動開発」を読んで、TDDの本質は「自信を伴うコードを書くこと」にあると感じました。 実際に本書では「テストは目的を達成するための手段であり、その目的とは、大いなる自信を伴うコード」と表現されています。 そしてそれはこれまでに紹介してきたプラクティスからも伺えますね。
ブログを書くために改めて読み返していると、まえがきに下記のように書いてあることに気がつきました。
- 「動作するきれいなコード」...が、TDDのゴールだ
- テスト駆動は、プログラミング中の不安をコントロールする手法だ
大事なことは最初にちゃんと書かれていました。
さいごに
「テスト駆動開発」の輪読会をチームで実施して得られた学びを共有しました。 本書を読むことで、なぜTDDをするのか、どうしてTDDが良いのか、その本質が少し分かったような気がしました。
チームでは、今までやってきたTDDのプラクティスが間違っていなかったという自信と、さらに良くするための学びを得ることができました。
本ブログでは紹介しきれていないプラクティスがまだまだたくさんありますので、TDDに興味がある方はぜひ「テスト駆動開発」を読んでみてください。
