はじめに

今やっているプロジェクトでサーバーサイドの実装をする時、テストファーストでやっています。
実装を進めて行けば行くほどテストファーストのありがたみを感じてきたので、その良さを羅列して書いておこうと思います。

ちなみに言語はKotlinで、テストフレームワークはこの前も書いたKotlinTestを使っています。

テストファーストでやってて良かったこと

後になるほど実装が楽になる

実装が進むに連れて徐々にロジックの量も増えてきましたが、テストコードがあるおかげでポチッと一発テスト流せば全ての動作確認できるので、安心して進められるようになりました。
もしテストコードがなかったら何度も「あのパターンと、あのパターンと・・・」とか考えながら色んな退行テストをしないといけないし、しかも大体漏れます。

あとそもそもサーバーサイドプログラムの動作確認は手動でやると、トークンとか気にしながら色々パラメータいじりながら叩かないといけないので、繰り返しやるのは面倒です。
なので作業時間も削減できるし、確実にテストもできるわけです。

まだやってないですが、これでリファクタリングとかも積極的にできますね。

設計が整理される

コードを書く時、基本的に頭の中で設計を考えてから実装すると思います。
それをプログラム設計みたいなドキュメントに起こす人もいれば、手書きで整理して書き始める人も。

テストファーストの場合、この設計で考えていたことをそのままテストコードとして書くような感じになります。
どうせ設計を考えて書く時間は取るし、それがテストコード書く時間に置き換わるだけと考えるとテストコード書くことによる時間のロスも少ないですね。

で、その設計を実現してエラーが出ないようにしていく形になるので、ドキュメントとか書き起こすより分かりやすいし実装しやすいんじゃないかなと個人的には思っています。

テストしやすい

これはよくTDDの解説でよく言われることですが、テストを先に書くことで、自然としっかりと分離された、テストのしやすい設計になります。
一通りの実装が終わった後にテストを書こうとすると、ちょっと都合の悪い設計になっていたりして苦労することがあります。
なのでどうせ書くなら先に書いておいた方が早いし、いい設計になります。

作業の目標にもなる

全部実装したあと「さあ、テスト書こう！」と思ってもなかなかモチベーション上がりづらいですよね。やっぱりロジック書いてる時の方が楽しいし。
でも、エラーになるテストコードを先に書いて、あとからロジックを書いてテスト通すってやってると、自分でゲームのクエスト作ってクリアしていってるみたいで楽しいです笑
「この時間までにここまでやる」みたいな目標にもなるし、作業を進めやすくなります。

あと、作業中断する時にテストコードだけ作ってエラーになるようにしておけば、作業再開する時に「なにやってたっけ？」を思い出すのにちょうどいいので、その思い出す時間も削減できますね。

言うまでもなく品質も上がる

当然ながら、テストをちゃんと書いてるので品質は上がります。
テストちゃんと通してることによる動作保証もそうだし、動作確認とかデグレの修正で取られる時間も抑えられるので、その分ゆとりができて作業の質も上がったり、潜在的な効果も大きいです。

結果早い

「時間なくてテスト書かない」はよくありますが、よっぽど超小規模(単純なAPI数本とか)でない限りはテスト書いた方が早いと思います。まだ実装途中の段階ですが、既に感じてます。
なのでサーバーサイドエンジニアの人は、是非単体テストをしっかり書いて欲しいですし、テストファーストで実装すると書きやすいのでおすすめです。