理論上のTDDのみ
1年ちょっと前、幸運にも9か月の休憩をとることができました。その時に、C＃のスキルを磨くことにしました。私は多くのプロジェクトに取り組み始め、TDDに従うことを余儀なくされました。 それはかなり啓発的なプロセスでした。 最初は大変でしたが、時間が経つにつれて、よりテスト可能なコードを作成する方法を学びました（実際には、よりソリッドなコードになる傾向があります）。 今、私は労働力に戻り、奇妙なことに気づいています。 私はTDDに従わないことを好みます。 TDDを使用すると速度が遅くなり、実際にクリーンなアプリケーションを設計するのが難しくなります。 代わりに、私はわずかに（大規模に）異なるアプローチを採用しました。 作業の垂直スライスを選択します 機能するプロトタイプを開発する すべてが整頓されるまでリファクタリングする 私が書いた美しく固くてテスト可能なコードに感謝します。 お気づきかもしれませんが、ステップ1は「テスト対象のパブリックサーフェスを定義する」わけではなく、ステップ2は「パブリックサーフェスからベジェスをテストする」わけではありません。また、どのステップにもテストが含まれていないことに気づいたかもしれません。私はテスト可能なコードを書いていますが、まだテストしていません...まだまだです。 ここで、実際にどのような種類のテストも行っていないことを明確にしたいと思います。私が書いているコードは動作します。手動でテストしているので機能します。 また、自動化されたすべてのテストを行っているわけでもないことを明確にしたいと思います。これは私のプロセスが異なるところです。そして、これが私がこの質問をする理由です。 理論的にはTDD。実際にはありません。 私のプロセスは少し進化しており、TDDと、非常に生産的で合理的に安全であると思われるテストとのバランスを取りました。次のようになります。 テストを念頭に置いて作業の垂直スライスを実装しますが、テストは作成しません。 そのスライスを修正する必要がある場合（1か月後など） 作業のスライスが正しいことを保証する単体テスト、統合テスト、動作テストなどを書く コードを修正する そのスライスを変更する必要がない場合、 何もしない テストを書く負担をコードを書く前から変更する前に単純にシフトすることで、はるかに機能するコードを生成することができました。そして、テストの作成に取り掛かるときには、作成するテストの数ははるかに少なくなりますが、ほぼ同じくらいの範囲（高いROI）をカバーします。 私はこのプロセスが好きですが、うまくスケールしないかもしれないと心配しています。その成功は、開発者が物事を変える前にテストを書くことに熱心であることにかかっています。そして、それはかなり大きなリスクのようです。しかし、TDDのリスクはまったく同じです。 だから、私は[BT] DD地獄に行くのですか、これは実用的なコーディングとテストの一般的な形式ですか？ 私はこのように働き続けたいです。このプロセスを長期的に機能させるにはどうすればよいですか？ 注意： 私は自分のプロジェクトの唯一の開発者であり、要件の収集、設計、アーキテクチャ、テスト、展開などすべてに責任があります。これが私のプロセスが機能している理由だと思います。