テストコードから書き始める

この記事はエンジニアと人生コミュニティのアドベントカレンダー（#1）の18日目です。

#2はこちら

はじめに

ここ半年〜1年ほど、部分的にテストコードから実装するようにしています。

「テスト駆動」というほどテスト中心じゃないな〜と思ったので、TDDという言葉は使っていないです。

もちろんその時々でやり方は調整しますが、
一番よく使う実装パターンとともに、「テストコードから書き始めること・テストコードを書くこと」のメリット・デメリットをまとめようと思います。

筆者の状況

• 開発の割合はバックエンド8割、フロントエンド2割

• チームではなく一人で実装することが多い

• 保守担当で、機能追加が多い(「SNS連携したいからAPIとデータ連携バッチ作って！」みたいな)

• テスト駆動開発は気になるところを拾い読みした(第1部が中心)

やり方(メソッド単位のテストを書く場合)

• メソッドの設計をする

  • 入力・出力・処理過程の考慮点を決める

• そのメソッドが一番使われそうな入力でテストコードを1つ作成する

• 設計した通りにメソッド本体を書く

  • 基本的にこの時点でメソッドは完成する

• テストコードを追加していく

• 考慮漏れが発覚したら随時メソッドを修正する

メリット

テストコードが揃えやすい

1つテストコードを書いておくと、2パターン目以降のテストコードが増やしやすくなります。

理由としては、2パターン目以降は入力のバリエーションを増やすだけで済む場合が多いからです。

特に入力としてレコードをセットアップする場合は、
1つ目を書く時にセットアップを書けば、2パターン目以降は格段に楽になります。

パラメタライズドテスト化しておくのもいいですね。

たまに1パターン目のセットアップを再利用しづらい時もありますが、
その場合は関数の責務が重すぎることが多いです。

一度腰を上げてしまえば、その後はテストコードを揃えやすくなります。

変更しやすい

テストコードが揃うので、変更がしやすいです。

自分が行った変更が前書いたコードを壊していないか、コマンド一つで確認できます。

開発中の仕様追加によりガード節を追加した場合などに、よく恩恵を感じますね。

テスト結果のアサーションに漏れがあるとそもそも意味がなくなるので、
そこは慎重に書く必要がありますが。

実装中のメンタルも安定しますし、一度この変更のしやすさを味わってからは、自然とテストコードを書くことが多くなりました。

デメリット

テストコードを書く分時間がかかる

テストコード無しの実装より時間がかかります。

理由としては、思考時間とコード量が増えるからです。

テストコードでも可読性や実行速度を気にする必要があるので、
設計・実装にそれなりに時間がかかります。

ただこれまでの経験だと、「コード変更時の時間・不具合の削減」によって開発全体では時間を節約できているような。

初期開発やスピードが必要な不具合修正などでは、この時間がネックになるかもしれませんね。

チームの文化によってはそもそもテストを書けない

チームのルールで「テストコードは書かない」となっていたら、勝手に書くわけにはいきません。

自分は現在一人で開発しているので、
PMに相談しつつ開発スタイルは自由に選べます。

ただ新規開発で、納期の都合から途中でテストコードの実装をやめたプロジェクトを見たこともあるので、そこは要相談ですね。

終わりに

自分の場合、以下の流れで実装することが多いので、テストコードの「変更しやすい」という恩恵をより大きく感じるのかなと思います。

• 要件が固まりきってない状態で降りてくる

• お客様に質問をして、その回答待ちの間に実装

• 回答を得られ次第、適宜コードを変更していく

テストコード利用の一例として、参考になったら嬉しいです。

読んでいただき、ありがとうございました。