C/C++でTDDする時の手順をステートマシン図で描いてみた

Test-Driven Development for Embedded C (Pragmatic Programmers)

James W. Grenning

Pragmatic Bookshelf

発売日：2011-05-02

ブクログでレビューを見る»

タイトルで描いてみたと言いつつ、「Test-Driven Development for Embedded C (Pragmatic Programmers)」の第3.7節「Test-Driven Development State Machine」より引用です。著者のJames W. Grenning氏はTDDの作業を以下のステートマシン図のように捉えると良いと書いています。

TDDの作業を状態遷移として表現したステートマシン図

※作業を状態として書いているので良い書き方じゃないのですが、そこは置いときましょう。

TDDをやっている人ならご存知だと思いますが、テスト対象を実装する前にいきなりテストを書いて、わざわざコンパイルエラーを起こすとこからやるのが大事です。そして、コンパイルエラーの次は、リンクエラー、テスト失敗と来てからようやくテストを通るように実装します。

この一連の流れをやる目的は、

• 今あるテストを通すための最小限の実装を常に維持する
• テストが通っていないなら、どこに問題があるか明確に分かるようにする

です。

まずはテストを書いて目標を定めておいて、エラーまたはテスト失敗で作業ステップを確認しつつ、1歩1歩歩いていくのです。本当に1歩ずつです。ちょっとでも道から外れていれば、そこ道外れているよ！と警告を上げてくれます。

（TDDをやらない人でもIDEを使っている人は、IDEについている構文チェックのサポートを受けてコードを書いているので似ているようなことをやっているかもしれません。）

TDDをやらないコーディングの場合、本人が気付かないだけで、作業と並行して細かなミスが蓄積していったり、実装モレがあったりします。実装が一通り終わったという状態になっていても、どこにバグや実装モレが潜んでいるか分からない状態でテスト or デバッグをすることになります。

しかし、このステップをきれいに守ることで、何か問題が起こっていれば明確に問題の箇所が把握できます。テストしていないとか、実装し終わっていないとか、不安定な状態でいる期間が短くなります。常に動くコードをさわっているという核心を持ち、非常に安心感をもって作業ができます。

慣れてくるとビシッと歯車がかみ合った状態で1個1個作業が進んでいる感覚が得られて気持ち良いです。少なくとも読書会をやっているときはきっちりTDDのステップでコードを書き続けてみます。