わかりました。私は以前、あなたが今しているように少し考えていたので、あなたの発言のいくつかにコメントし、あなたの発言の別の視点を与えるだけだと思いました. おそらく、これは、テスト駆動開発が実際に行うコーディングの異なるアプローチに光を当てる可能性があります。
自動テストのアイデアが回帰を防ぐことであることは理解していますが、そもそもそれがどのように問題になるかわかりません。
多くの場合、回帰は、以前のコードの動作を十分に理解していない状態で行われた単純な変更ではありませんか? そうである場合、後の段階で誰かが破壊的な変更を行った場合に自動的に検出できるように、すべての開発者がコードの機能を文書化するようにするにはどうすればよいでしょうか? 単体テストはおそらく役立つでしょうか?
モジュール化されたオブジェクト指向の簡潔なコードで、十分にコメントされている場合、回帰の問題はありません。
ドキュメントが非常によく書かれているため、誤解することはほとんど不可能であり、その後のプログラムへの各変更は、十分に熟練したコーダーによって外科的に正確な方法で行われると仮定すると、回帰の問題は発生しない可能性があります。実際、古い動作を変更することは決してありません。
単体テストを動作を文書化する方法と考える場合、それは古いコードの機能を伝達するのに同等またはより効果的な方法ではないでしょうか?
もちろん、テストによって文書化が妨げられることはありませんが、ツールにはそれぞれ長所と短所があります。
最初に正しく構築し、将来発生する避けられない機能の追加に備えて設計すれば、テストは必要ありません。
私の意見では、最初からすべてを正しく柔軟に構築するためのコストと労力は膨大であり、多くの場合、システムが過度に複雑になり、開発ペースが遅くなります。
自問してみてください: 柔軟性のコストはいくらですか? あらゆる問題に対していくつかのソリューションを構築し、それらの間の実行時の切り替えを容易にすることで、リスクを最小限に抑えていますか? それとも、実行時にパッチを適用できるプラグイン システムを構築していますか? これらの戦略は両方とも、開発時間とプロジェクトに複雑さを追加することの両方で、非常に高価です。
今必要なものだけを構築し、必要に応じて修正を迅速にコーディングできるようにチームとして十分な柔軟性を維持しようとすると、実装ごとにどれだけの時間と労力を節約できますか?
既存の機能をテストした場合、機能の拡張は容易になりますか?
さらに、それは適切なエラー処理とロギングが
達成すべきことではないでしょうか? すべての外部依存関係が最初に可用性を再確認できることを確認できるのに、assert ステートメントと単体テストのハッシュ化に何週間も費やす必要はありません。
適切なエラー処理とログ記録はフォールバックとしては良いかもしれませんが、障害回復は正確さの代わりにはなりません。「優雅なエラー処理」と「可用性の再確認」と言うとき、あなたが何を指しているのか正確にはわからないので、これ以上コメントできないと思いますが、これは回復のように聞こえます。エラーが発生しないことは、エラーから回復できることよりもはるかに優れています。
単体テストは、欠陥があり、不十分に構築された「悪い」コードベースの松葉杖であるという結論に達するのは傲慢ですか? これは深刻な問題です。どこにも良い答えが見つかりません。私が自動テストの目的に疑問を呈すると、誰もが私が荒らしだと思うようです.
ドキュメントや適切なコーディングの原則を避けるための言い訳として、単体テストを使用することは確かにできます。これは私が多くの場所で見てきました。しかし、ツールボックスに追加して、製品の正確性、シンプルさ、柔軟性を高める優れたツールでもあります! 新しいチームで頑張ってください。バグを回避するのに役立つ優れたドキュメントやその他の原則について、彼らに 1 つか 2 つ教えることができると思います。また、指数関数的な複雑さの増大を回避しながら、より迅速かつ少ない労力で製品を開発するのに役立ついくつかの原則をおそらく提供してくれると思います。