OpenWork Tech Blog

社員クチコミサービスを運営しているオープンワークエンジニアによるテックブログです。

オープンワークでテスト駆動開発(TDD)を導入するまでの6ステップ

Webアプリチームの西川です。

オープンワークでテスト駆動開発を導入したのですが、その時の反省も踏まえて手順をまとめてみました。

ステップ1. なぜ導入するのかを明確にする

アプリケーションが動作する綺麗なコードを書く

これが刺さるなら一番良いです。 当社もこの目的から始めましたが少し意識が高すぎたかなと思い、今は

テストコードを書くコストを減らし、メリットを増やす

に変更しています。

テスト駆動開発で減らせるコストとメリットは以下のように考えています。

減らせるコスト

  • 仮実装、三角測量を行うことで少しずつテストコードを作ることができ、最初のテストコードを書くコストを減らすことができる

メリット

  • テストコードのテストになる
  • リファクタリングを短いサイクルで実行できる
  • 早い段階から自信を持って開発を進められる
  • 楽しい

私はいわゆるサラリーマンエンジニアで、仕事以外ではほとんどコーディングをしていません。
正直コーディングはあまり好きではありません。
コードを書かずに課題を解決できるならそれが一番良いと考えるタイプです。
そんな私でもテスト駆動開発を行うことで開発の楽しさを感じることができました。
おそらく、短いサイクルで思った通りの結果が出るのが楽しいと感じているのだと思います。

ステップ2. 社内に布教する

t_wadaさんの動画を見る

以下の動画が本当に素晴らしいです。この動画を見るだけでテスト駆動開発のイメージを掴むことができます。

youtu.be

ボーリングゲームのハンズオン

ボリューム感がちょうど良く、とても説明がしやすいです。

butunclebob.com

ステップ3. 練習する

kataを作って練習してもらいました。

github.com

kataを作らなくても、atcoderの以下のような問題をネタに仮実装、三角測量、実装の流れを練習することも可能です。

atcoder.jp

ステップ4. テストファーストからやってみる

バグ修正をテストファーストでやるところから始めます。
バグを修正するに当たって、まずは「バグの再現(手動テスト)」から始めますが、
ここを「バグの再現(自動テスト)」に変えるだけで良いので敷居が低いです。(もちろん物によってはテストコードで再現することが難しいケースもありますので、その時は諦めます。)

※当社ではこのステップを踏まなかったため、やっておけばよかったと感じたステップになります。

ステップ5. TODOリスト(テスト観点リスト)を作る

あるプロジェクトでは、開発を始める前にテスト観点リストを作るようにしていたのですが、
これがほぼテスト駆動開発のTODOリストと同じ物だったので、そのプロジェクトではテスト駆動開発を導入しやすかったです。

TODOリスト(テスト観点リスト)を作る敷居は特にないと思いますので、ここから入るのもアリかもしれません。

ステップ6. ペア/モブプログラミングでやってみる

一人だと実装から始めたい欲望に負けてしまうので、まずはペア/モブプログラミングでやってみることをおすすめします。

techblog.openwork.co.jp

まとめ

テスト駆動開発の導入はできましたが、浸透するレベルにはまだ至ってません。
トップダウンでテスト駆動開発をやってもらうことも可能ではあるのですが
良いものが自然と広がるようにしたいので、地道に草の根活動を続けていきたいと思います。

最後に

テスト駆動開発でテンポ良く楽しく開発をしたい方、是非一緒に働いてみませんか? vorkers.jp