1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

hacomonoAdvent Calendar 2024

Day 13

スクラムチームへTDDを導入した話

Posted at

この記事は hacomono advent calendar 2024 の13日目の記事です。

この記事は?

hacomono開発本部でプロダクトエンジニアをしているすがじゅんと申します。
最近私のチームではスクラム開発を始めて、その過程で一部テスト駆動開発を導入してみたので実際にやってみて感じたことや、メリット・デメリットなどを書いていこうと思います。

TDD is 何?(そんなの知ってますよという方は飛ばしてください)

TDDとはテスト駆動開発(Test-Driven Development)の略称です。
テスト→実装→リファクタリングを繰り返し行っていく開発の手法の一つで、機能実装前にテストコードから書くのが大きな特徴です。ここで細かくは述べませんし、詳細はいくらでも記事があるのでこれくらいにしておきます。

一般的なTDDの進め方としては、

  1. 対象機能に対して失敗するテストを書く
  2. 1を元に機能実装し、テストをパスさせる
  3. リファクタリングを行う

というサイクルを繰り返すというものです。
メリットとしては確実にテストコードが生まれるので、コードの安全性が高まること、後回しにされがちなリファクタリングを都度行えること、バグ発生率の低下、などが挙げられます。

TDDは死んだのか?

TDD反対の意見があることも理解しています。
一番の理由は開発速度の低下によるアウトプット量減でしょう。何よりスピードを重視する開発において、TDDを選択するケースは稀だと思います。
また、TDDをやってもそもそも全ケース網羅的に書けていないケースもあり、だったらそんなにテストに時間かけなくてよいのでは?という意見もあるかと思います。

ですが私は場面によってTDDを採用することにはメリットがあると思います。その理由をこれから述べていきます。

致命的なやり直しが減る

私がTDDで最もメリットに感じる点はここです。
1の工程でまずテスト観点を洗い出すことになると思います。この洗い出し作業がとても重要で、はじめに実装予定の機能についてかなり深掘ることになります。

  • ユーザーが本来必要としている要件を満たせているか?
  • 別の機能が関わったときに発生するバグはないか?
  • 組み合わせのケースは十分か?

などはじめにがっつり洗い出しの時間を取ります。ここが正確であればあるほど、のちの工程でやり直しの発生リスクは減ってくると思います。

結果的に、「8割くらい実装終わったんだけど本来やりたかったことはこうじゃないんだよね」という地獄のような展開を回避することができます。

QAに情報をシェアできる

これはチーム開発の副次的効果のようなものなのですが、開発の早い段階でQAメンバーに情報を渡すことができる、というのも大きなメリットです。

参考までに私のチームではざっくりと

  1. テスト設計
  2. 実装
  3. テスト実施

のようなサイクルでスプリント内のタスクを進めているのですが、テスト設計はこれまでQAメンバーが単独で行っていました。
TDDでは、前述の観点洗い出し作業を開発者とQAメンバーが一緒に行います。
すると、開発者視点では一人では気付けなかった観点洗い出し漏れに気づける可能性も高まりますし、QA視点では開発者がどのようなケースを想定しているのか理解することができます。
結果として、QA一人で機能をキャッチアップするより早めに設計を完了することができますし、なによりテスト設計の精度が上がります。

リファクタリングできる

リファクタリングって後回しにされませんか?
実際自分も「xxまでにリリースしたいから、リファクタのチケット切っておいて後でやろう」として1年以上放置したことがあります。1年放置されたらそのチケットが再開されることはもうないでしょう。
TDDでは一つのケースをパスさせたら、一旦リファクタリングを行って(もちろん不要な場合もあります)からまた次のテストを作る、というように小さなサイクルを回して行きます。

そのため、都度リファクタをする機会があります。
実装が増えるに従って、リファクタリングしたくなる箇所はどんどん増えていくと思いますが、その過程でコードも整理されてきれいになっていきます。

サイクルの中にリファクタリングの機会があるのはTDDの大きなメリットであると言えます。

で、結局TDDはやるべきなの?

冒頭も述べたのですが、現状は「部分的に採用していく」というのが最適解かなと思っています。
具体的には重要なビジネスロジックの変更や複雑なユースケースには適していて、シンプルな変更には過大である、という意見です。

どうしてもタスク完了までのスピードは低下してしまう傾向はあると思うので、リリース時期や重要度、複雑度を加味してやるかどうかを決めていくのが良い落とし所ではないでしょうか。

実際にやってみてこれまで挙げたようなメリットも享受できたので、私は今後もTDDと良い付き合い方をしていこうと思っています。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?