今までやりづらくてテストを先に書くことを倦厭していたが先に書くことの良さを知った話

よくテストから書いたほうが良いと聞く。
過去は、バックエンドの複雑さからテストを先に書くことが辛く、ついつい後回しにしていた。

- テストを先に書くことの利点

明確な目標を定められる

結局どうなればいいんだっけ？から解放される。
（様々な条件により過程が変わることもあるが、それこそテストのパターンを増やせば補える。）
テストが通らないということはどこかが明確に間違っている証拠なので、
結果として今までのように画面からテストして
実装漏れを見つけるやり方よりも開発スピードが上がったように思う。

実装をテストに合わせる形で進められる

仕様変更があった場合、テストを先に直すと当然テストが通らなくなる。
なのでテストが通れば基本的に実装完了ということになる。
また、これは少し話がずれるが複数テストケースがあると、
後々機能の仕様変更や追加時、またはリファクタリングなど、
後方互換性も担保しやすくなる。

- 現在のプロジェクトについて

現在のプロジェクトではGoで開発を行っているのだが、
良いと思った点を下記に記述する
・テスト用のデータベースを作成している
もし共通の定数などがあれば環境構築時点で最低限のデータを投入しておけばよい。
テストに必要なデータはテスト実行時に投入して、テスト後に削除している。

・関数名に日本語を併用しており、なんのテストケースなのかすぐわかる
日本語も記述できるのは驚いた。
もし複雑な条件だったりテスト観点が複数ある場合は、
関数の最初にコメントで書いておけば関数名自体は簡素でもわかりやすかった。

・単体でテストを実行できるようにする仕組みがある
vscodeでrun testを行えばすぐ単体でテストできるような仕組みを作ってあったのがまた良かった。
なぜかLaravelのプロジェクトの時はテストがやたら重く完了するまでに１０分以上かかり、
またファイル単位でしかテストが実行できないため不便だった。
おそらくテストも最適化が必要で、DBの処理に時間がかかっていたように思う(毎回作っては削除していたように思う)
また、プロジェクトが肥大化すればするほどすべてのテストを実行すると完了までに時間がかかるため、
単体でテストを実行できるようにする仕組みがあるとテストファーストが浸透するように思う。

- まとめ

バグを生まないためには開発に関わる全てのことがストレスフリーでないとならないと思った。
今回はテストに重点を置いているのでテストについて考慮すると、
テストが大事だということをわかってはいても、テストが書きづらいとおざなりになってしまうこともあるだろう。
テストケースがどこまで書かれているのかすぐわからなければ、追うのが大変で漏れてしまうこともあると思う。
テスト実行に時間がかかれば、なるべくテストケースは最低限で済ませたくなり、観点が足りないまま見過ごされてしまうこともあるかもしれない。
どうひっくり返っても開発とテストは切り離せないので、テスト周りの整備の重要性について書いた。