Cake.jpとテスト駆動開発

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

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

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

導入の背景

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

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

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

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

※弊社のモブプロについて: 「コンテキストの共通化」を加速させるために1年以上モブプロを続けた結果

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

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

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

複雑度が高い 複雑度が低い
新規開発 ×
追加開発 ×
不具合修正 ×

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

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

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

新規開発 × 複雑度が高い

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

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

追加開発 × 複雑度が高い

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

  • ファットコントローラーで機能追加が辛い
  • それ以外

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

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

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

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

不具合修正 × 複雑度が高い

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

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

成果

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

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

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

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

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

さいごに

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

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

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

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