一人で新規開発する時テストはどのように書き進めればいいか

一人でシステムの新規開発をする場合、どういったタイミングでテストを書きはじめ、どのように書いていけばいいかを考察してみた。ターゲットとしては一人でサービスを開発する個人開発者、スタートアップ等で一人のエンジニアのみで開発を進める場合など。

いつから書きはじめるのか

「一人で」システムの新規開発をはじめた当初、まずはテストを書き始めるべきではないと思う。

なぜかというと、新規開発当初に必要なものというのはシステムの安定性ではないからだ。まだリリースもしておらず、身内に確認してもらうためだけのものにテストを書いて時間を消費するのはもったいない。

まずはひたすら開発を行う。闇雲に開発を進めるのではなく、なるべく多くの箇所を網羅できるように、薄く広く開発していく。そうすることで不明点やもっと検討が必要であるべき箇所が見つかり、それを企画サイドの人間に共有することで早めのプラン改善を行うことができる。

いきなり丁寧にテストを書きはじめてしまい、だいぶ日数が経過してから大きな問題が見つかり「実は予定していた機能は今の方法では実現できないんだ」なんてことになったら大問題だ。ただでさえ無駄なものを開発することに時間を費やしてしまっているのに、さらにテストを書くのにも時間を費やしてしまうことになる。時間はもう二度と取り戻せないのにそんなことをやっている場合ではない。

そういった理由でまずはテストを書くべきではない。

一人での開発に求められること

そもそも一人で開発を行う場合に求められること（もしくは自分で求めること）というのは、単なるプログラム開発だけではない。

ちょっと仕様を変えれば格段に開発がしやすくなるのであればそれを企画サイドに提案してみたりすること等も重要だ。こういったことは必須ではないが重要で、開発者一人だけの時にこういった連携や提案を率先してできない場合、トラブルの原因にもなりうる。

同様にテストをどう書いていき、どのように時間を節約し、どのようにスムーズな開発を提供できるかというのは一人の場合非常に重要となる。考えることを放棄してむやみにテストを大量に書いていくべきではない。

ではどのように書いていけばいいのか

とりあえず一通りの機能はテストなしで作成していくべきだ。問題点や仕様の変更の必要性がある箇所の洗い出しが終わり、ある程度企画サイドとのやり取りも落ち着いてきた時期に、リリースに向けてどんどん書いていくべきだと思う。

一応「一人で」という体にはなっているが、複数人の時でも考えることは放棄せず一応方針は決めたほうがいいと思う。人数が多い時は最初からテストを書いていった方が望ましい場合は多いかもしれないし、２，３人の時は書かない方がいいかもしれなし、書いた方がいいかもしれない。

まずはその都度その状況において、書くこと、書かないことのデメリットを必ず検討してみよう。