実務でTDDを導入するときの検討事項 - Spring Bootで学ぶTDD 第14回

はじめに 🔗

これまで13回にわたり、TDDの技術的な手順を学んできました。ここまで進めた皆さんは、自分でテストコードを書き、機能を実装できる

力

を身につけています。

ただ、学校や個人のプロジェクトから職場の実務に移ると、事情は少し変わります。

「こんなに忙しいのに、いつテストを書くんですか？」

「テストを書いたら、スケジュールが2倍に延びませんか？」

こうした現実的な疑問に直面します。今回は、TDDを実務に適用するときの

コスト

と

折り合いの付け方

を率直に考えます。

テストを書くコストと生産性 🔗

「TDDでは開発に時間がかかる」と思う人は多くいます。

初期段階では確かに時間がかかりますが、全期間で見ると、かえって速く進みます。

生産性の推移 🔗

開発の初期段階
テストを書かずにどんどん実装するほうが速く進みます。設計を吟味せずコードを書けるからです。TDDでは設計とテストの両方が必要なため、遅く感じられます。
保守段階
機能が増え、コードが複雑になると状況は逆転します。テストがないと、変更のたびにバグが出て、修正で何日も夜更かしすることになります。TDDで書いたコードには
安全網
があり、素早く思い切った変更ができます。

TDDは、将来の自分のために時間を投資するようなものです。今の1時間を使い、将来の残業10時間を防ぐと考えられます。

何をテストし、何を省くか？ 🔗

実務では、すべてのコードにテストを書くのが難しいこともよくあります。そこで

優先順位を付けて集中する

必要があります。どのコードを必ずテストし、どこを省いてもよいのでしょうか。

必ずテストするコード（Core）
決済、精算、割引計算など、お金に関わるロジック。
営業時間の判定やランクの算定など、複雑なビジネスルール。
頻繁に変更する箇所や、エラーの影響が大きい箇所。
テストを省略できるコード（Trivial）
単純なGetterやSetter。
単純なBean登録など、フレームワークに任せている設定。
他システムとの単純な連携。外部ライブラリそのものをテストする必要はありません。
単純なUIの配置やデザイン要素。

不安があるならテストしましょう。「これが壊れることはあるだろうか」と思うほど単純なら、思い切って省いてもかまいません。

チームでの導入と理解の得方 🔗

自分はTDDの利点を知っていても、チームメンバーは知らないかもしれません。「チームでテストを書く習慣がないのですが、自分だけ書いてもいいですか？」とよく聞かれます。

まずは自分から始める 🔗

最初からチーム全体のプロセスを変えようとしなくてかまいません。

バグが見つかったら、まず再現するテストを書きます。
コードを直し、テストが通ることを確認します。
自信を持ってデプロイします。

しばらくすると、チームの人が気づきます。

「あの人のコードはバグが少ないな」

「あの人はコードの変更をあまり怖がらないな」

チームが興味を持ったときが機会です。TDDを試した経験を共有すると、その習慣が自然に広がります。言葉で説得するより、

結果

で示すほうが説得力があります。

レガシーコードを扱う（Legacy Code） 🔗

新規プロジェクトに限らず、テストなしで書かれた巨大なレガシーコードに出会うこともあります。一気に全部をテストで覆うのは現実的ではありません。

ボーイスカウトのルール 🔗

「立ち去るときは、来たときよりもきれいにしておこう。」

このルールをコードにも適用します。コード全体に手を入れる代わりに、

今日変更する箇所

にテストを書きます。

変更するコードの周囲に*安全網（テスト）*を張ります。
コードを修正し、リファクタリングします。
コミットします。

このように、テストする範囲を少しずつ広げるのが、最も現実的で安全な方法です。

おわりに 🔗

TDDは、よりよいソフトウェアを作るための

習慣

であり、

道具

です。厳格に守ることにこだわりすぎなくてかまいません。

コスト
。初期費用はかかりますが、保守のコストを大きく減らせます。
範囲
。中核のビジネスロジックを中心にテストし、単純なコードは省けます。
チームワーク
。押し付けず、まず自分で始めて安定性を示しましょう。
レガシー
。手を入れる箇所から少しずつ改善しましょう。

皆さんは、TDDという強力な道具を手にしました。いつ、どう使うかの判断は、経験を重ねるにつれて磨かれます。

次回はいよいよ最終回です。これまでの
Spring Bootで学ぶTDDの内容を振り返り
、今後の学習の方向を示してシリーズを締めくくります。

参考 🔗

Working Effectively with Legacy Code（Michael Feathers）↗
テストのないレガシーコードを安全に変更する戦略を扱った名著です。
パレートの法則（80対20の法則）↗
結果の80%は原因の20%から生まれるという法則で、テストカバレッジの戦略にも応用できます。