コーディングしているときに、単純なコードの再利用の機会に遭遇したとします（たとえば、ユーティリティクラスや基本クラスなどのアクセス可能な場所に一般的なコードを引き出す）。「これを行うのは良いことですが、今すぐ行う必要があります。このコードを変更する必要があり、別の場所で変更するのを忘れた場合、テストフレームワークはお知らせ下さい。"
言い換えれば、あなた（または別の開発者）が書いた素晴らしいテストを許可して、他の場所でもコードを変更するように思い出させます。
これは、私たち自身または他の開発者に見られる可能性のある正当な問題ですか？
ユニットテストがTODOリストの方法としてそれらに依存することを奨励するかどうかを尋ねていますか？はい、でもそれはずさんなコーディングではないと思います。結局のところ、単体テストが失敗し、テストのコードを作成することから始めなければなりません。いくつかのコードをリファクタリングしてから、もう一度テストにコーディングする場合、それはずさんなコーディングではありません-それはあなたが想定していることを実行しています。
単体テストの問題は、単体テストですべてのコーナーケースをカバーできないことだと思います。また、動作テストは動作するアプリを意味すると思われることもありますが、これは真実ではありません。
あなたが提供する例では、良いテストは実際にあなたがずさんなデザインを実装することを可能にします、しかし私の経験では、悪いテストはあなたが同じことをするのを思いとどまらせることはなかったでしょう。
あなたの議論の誤謬は、「これを今やること」は、ずさんな設計を実装することによって時間を節約することを意味するという前提に集中しています。問題の真実は、あなたのテストが良いかどうかにかかわらず、あなたは技術的負債を負っているということです。そのコードに変更を加えることは、それを思い出させるための優れたテストフレームワークがあるかどうかに関係なく、はるかに複雑なタスクになりました。
未熟なコードは正常に機能し、顧客に完全に受け入れられる可能性がありますが、量が多すぎるとプログラムがマスターできなくなり、プログラマーの極端な専門化につながり、最終的には柔軟性のない製品になります。-ウォードカニンガム
優れたテスト手法の強みは、ある程度の安全性を備えた債務を負わせることにあるかもしれません。選択の結果、コードのこの領域が現在弱いことに気づき続ける限り、トレードオフの価値があるかもしれません-より高い負債を犠牲にして、より低いコストで、より早く製品を出荷しますその結果、短期的にバグが発生するリスクがあります。
テストが良好で、コード（ずさんなものかそうでないもの）がテストに合格した場合、すべてが良好です。良いコードがあればいいのですが、壊れたコードよりも動作が悪いコードの方が優れています。
変更が必要なコードを見つけるための最初のオプションとしてテストを使用しません。IDEの検索（またはリファクタリング）機能を使用して、問題のメソッドを呼び出すすべての場所を探します。
テストは、私が誤ってだらしなくなったり、誤ってバグを導入したりした場合に備えて、ちょうどいい追加です。テストは最初から私をだらしなくさせません、私が終わったと思うと彼らはただ私を安心させます。
良いテストを行うことで、ずさんなコーディングを修正できると思います。
あなたは確かにテストの有無にかかわらず信じられないほどずさんなコードを書くことができます。ユニットテストを使用すると、それを回避するのが少し簡単になりますが、短期的にのみです。
コードの2つの場所に一連のロジックをコピーしている場合（IMOは開発者が実行できる最悪のことです）、おそらくテストにも一貫性がありません。
プログラマーができる最も重要な仕事は、コードを容赦なくリファクタリングして、すべての重複を取り除くことです。これは、ほとんどの場合、1回の反復でもメリットを示します。
コピーされたコードに2つの場所でエラーが発生した場合、テストの方が優れていると思うのはなぜですか。
ずさんな開発者とずさんなコーディング慣行があなたの例のずさんなコードにつながっているように私にはもっと聞こえます。あなたが説明したテストは、ずさんなコードがこれまでに到達するのを防ぎます。