私は小さな会社でソロ開発者として働いています。私は実際に会社で唯一の開発者です。定期的に書いて保守しているいくつかの(比較的)大規模なプロジェクトがあり、それらをサポートするテストはありません。新しいプロジェクトを始めるとき、TDDアプローチを試してみるべきかどうかとよく疑問に思います。それは良いアイデアのように聞こえますが、私は正直に関係する余分な仕事を正当化することはできません。
私は自分のデザインを前向きに考えようと努力しています。いつか別の開発者がコードを保守するか、少なくともトラブルシューティングを行う必要があることは確かです。できる限りシンプルなものにし、把握するのが難しいものをコメントして文書化します。そして実際、これらのプロジェクトはそれほど大きくも複雑でもないので、まともな開発者は理解するのに苦労するでしょう。
私が見たテストの例の多くは、コードのすべての面をカバーする詳細にまで及びます。私が唯一の開発者であり、プロジェクト全体のコードに非常に近いので、手動で書き込みをテストするパターンに従う方がはるかに効率的です。また、要件や機能は頻繁に変更されるため、テストを維持するとプロジェクトにかなりの量のドラッグが追加されます。そうでなければビジネスニーズの解決に費やすことができる時間。
そのため、毎回同じ結論に達します。投資収益率が低すぎます。
私は時折、雇用日に基づいて誰かが会社にいた年数を計算するなど、アルゴリズムを正しく記述したことを確認するために、いくつかのテストを設定しました。しかし、コードカバレッジの観点からは、コードの約1%をカバーしています。
私の状況では、ユニットテストを定期的に行う方法をまだ見つけることができますか、それともそのオーバーヘッドを回避することを正当化できますか?
更新: 除外した私の状況に関するいくつかのこと:私のプロジェクトはすべてWebアプリケーションです。すべてのコードをカバーするには、自動化されたUIテストを使用する必要がありますが、それは手動テストよりも大きなメリットが見られない領域です。