こんにちは、Cake.jp技術部でエンジニアをしている山内です。

この記事では、Cake.jpのエンジニアがどのような場面でテスト駆動開発（以下、TDD）を取り入れているのかについて話します。

※今回はTDDがどのようなものかは割愛させていただきます。

導入の背景

前提として、3年ほど前はテストコードがあまりない状況でした。

そこから、チームとしてレガシーコードに立ち向かうために、テストコードを書くということを推し進めていきました。

中にはTDDを実践しているメンバーもおり、週2で行なっているモブプロの中でTDDが行われ、さらに小話会（好きに技術の話をする時間）で共有されたりということを経て、社内でもTDDが広がっていきました。

個人的には、書籍などでもよく言われる「テストを書きやすいコードを書くことで、設計が良くなる」というのも感じていますし、TDDがうまくはまった時はゲーム感覚で実装できるという楽しさもあり、積極的にTDDを取り入れています。

どのような場面で採用するか

TDDを取り入れているとは言いましたが、全ての開発で取り入れているわけではありません。

傾向としては以下のようになります。

複雑度が低いケースでは、TDDは行わない（テストを書かないという意味ではないです）ケースが多いです。

そういった場合は、今までやってきたことに似た実装であるケースが多いので、ササっと書いてしまっています。

複雑度が高いケースについて、それぞれ補足していきます。

新規開発で複雑度が高いので、TDDチャンスです。

特に補足も必要ないと思います。

ここを△としていますが、大きく分けて二つのパターンがあります。

分類がアレな感じはありますが、、、

1番目のケースはそもそもテストを書くのが辛いパターンです。

弊社のサービスはコードベースだと10年選手で、当時から膨れ続けているようなコントローラーも存在します。

丁寧に剥がしていけば良いという話ではあるんですが、機能追加の頻度が高くない場合が多いので、そこまでリファクタ工数を取れないのが現状です。

こちらも△としていますが、多くの場合は不具合用のテストケースを先に追加して、それを通すための実装をしています。

テストファーストで不具合修正をしているものの、「レッド／グリーン／リファクタ」というthe TDDな開発ではないので、△としました。

一言で言うと、不具合が減りました。

ただし、TDD一本で不具合が減ったというわけではありません。

僕が入社した当初（2022/08）は今と比較して、不具合が多く発生していました。

不具合が出るたびに振り返り→改善を繰り返していきまして、今では不具合が激減しました。

不具合が減った理由の一つに、TDDがあると思っています。

Cake.jpでは、TDDに限らず良いと思ったものは積極的に取り入れていっています。

また、輪読会などで得た知識を積極的に活かしていくこともしています。

学んだことを活かすことに肯定的、かつ、積極的な良いチームだと感じています。

引き続きインプットとアウトプットを繰り返して、より良いサービスを目指していきたいと思います。