コーディングテスト-最初に、私のコードのおそらく3/4が単体テストであることがわかりました。私が本当に極端で、失敗した単体テストを修正する以外にコード行を記述しなかった場合、この比率はさらに高くなります。これらすべての単体テストを維持すると、コードの変更に大きな慣性が加わります。早い段階で、私はそれを吸い上げて修正します。プレッシャーがあるとすぐに、私はbroken_unit_tests「時間があるときに」再訪するためのディレクトリに行き着きます。デザインが結晶化する前に、TDDが高カバレッジを開始するのが早すぎるように感じます。
このジレンマから抜け出し、私が想定しているように変化する要件を歓迎し始めるにはどうすればよいですか？
プログラマーの規律の側面を脇に置いて...（バディビルドを行わずに、またはすべてのテストを修正せずにチェックインしても問題がない場合は、個人的なことです。アジャイルは高い規律を前提としています。圧力下:)、
1つの変更を行うと複数のテストに失敗する場合は、テストに問題があるという匂いがします。脆弱なテストは、TDDを使い始めるときによく見られます...コードを修正するよりもテストを修正することに多くの時間を費やす場合...停止し、呼吸し、反映します。症状ではなく病気を直してください。
コードスニペットがある場合は、話し合うことができます。現状では、私はあなたを大いに助けることができるとは思いません...
ガイドライン：テストは1つの理由だけで失敗するはずです。逆に、失敗するすべてのテストは、欠陥の正確な一意の場所を指摘する必要があります。同じ変更が原因で2つのテストが失敗することはありません。アーキテクチャレベルの抜本的な変更を行わない限り、これはまれなことです。
私はあなたがそれを逆に持っていると思います。単体テストを壊す可能性のある変更を実装する場合は、最初に単体テストを更新する必要があります。このようにして、壊れた単体テストと動作するコードを取得することはありません。コードの準備ができていないためにユニットテストが失敗するか、両方の部分が正常に機能します。
それがオーバーヘッドであると思われる場合は、将来のバグ修正にかかる時間を考えてみてください。
また、短いサイクルで作業を試みることもできます。つまり、代わりに
試す
締め切りが迫っており、マネージャーが肩を並べている場合、ユニットテストの膨大なバックログを処理するのは困難です。コードとテストを同時に行うことは、習慣に入ると実際には簡単です。
ユニットテストはかなり不変でなければなりません。
テストを作成し、そのテストに合格するためのコードを作成し、他のテストを中断する場合、新しいコードは「間違っている」と見なす必要があります。
明らかに、APIコントラクトを変更した場合にテストを書き直す必要がある場合もありますが、ほとんどの場合、TDDを実行する有効な方法として「テストの書き直し」を検討するべきではありません。
アイデアは、適切な動作をテストしなくなった単体テストを捨てて、新しいものを書くことだと思います。実装ではなく動作を反映するように単体テストを作成するのも良いことです。したがって、それらは設計からより独立したものになります。
一般的に、私はとにかくTDDの支持者ではありません。:)
テストの焦点が十分でないか、システムの依存関係が多すぎる可能性があります。
私がコードの非常に重要な側面を変更するとき、私がほとんどの場合行うことは、変更を加えるための新しいテストスイートを開発することですが、古いものを壊すことなく、ソフトウェアは古いものと新しい方法を並行して一度に動作させますリファクタリングに満足しています。古い方法のコードと古い方法のテストを削除します。
100％明確かどうかわからない...