TDDとRefactoring the "system under test"

Question

私は初めてTDD方法論を適用したプロジェクトに取り組んでいます。 要件が変更され、いくつかのクラスの動作とAPIを変更するまで、すべてうまくいった クラスの動作を変更すると、結局いくつかの変更が行われました。 テスト側からこのプロセスを開始する方法がわからなかったので、コードを変更し始めました。 テストコードで多くのコンパイルエラーが発生してしまいました。 しかし、問題は、私が以前にカバーしていたものがテストでカバーしているかどうか分からない。 書くとき、私は私がテストを追加したとして、作品によって量産コード部分を追加 が、私が変更されたすべてのテストクラスの上に移動して、確認するために持っているように、今そう：

1. 各テストがまだ関連
であること
2. リファクタリングしながら、私のセーフティネットを与えるために、テストが

TDDを想定している任意の偽陽性または偽陰性を生成しませんミッシングテスト

がないこと。ではない？ 私の場合は現在現れているので、それは私には分かりません。

私は間違っていますか？ これはそのようなリファクタリング作業を行う方法ですか、それとも良い方法ですか？

Answer 1

A）リファクタリング：外部で観察可能な動作を変更することなく、コードの構造を改善する。 （ここで外部とはテスト中のコンポーネントの外部を意味します）

あなたはAPIを変更していると言いますから、これは動作の変更を意味するので、リファクタリングではありませんでした。それは批判ではなく、ただの観察です。

実際にリファクタリングする場合（外部で観察可能な動作を変更しない場合）は、テストを変更する必要はありません。変更が必要な場合は、（コンポーネントの動作とは対照的に）コンポーネントの実装にあまりにも強く結びついています。

B）後で、テスト側からこれらの変更をどのように乗り越えたのかを確認できますか？変更を推進した要件を完全に理解しましたか？

私はシステムテストの自動テストを考慮します。要件が変更された場合は、影響を受けるドキュメントの一部を探し、新しい要件を反映するように変更します。テストは失敗する可能性が高いですが、今は実装を変更するドライバがあります。あなたがテストで複数の場所で同じ変更を行ったことがわかった場合は、DRY（Do not Repeat Yourself）というアプローチを適用しなければならないかもしれません。重複したコードによって提供される機能を、単一の場所（クラス/メソッド）にローカライズする。 BuilderやObject Motherのパターンを利用して、データ構造の偶発的な変更からテストを保護します。