私はTDDで練習しており、テストを満たす最も単純な実装を行いました。2 回目と 3 回目のテストの後、ロジックの一部を依存関係に抽出できることがわかりました。既存のテストはどうすればよいですか? それらをそのままにして、この依存関係を間接的にテストする必要がありますか? または、テストを「書き直して」、元のケースでスタブ/モックを使用してそれらを分割する必要がありますか?
4 に答える
3
元のテストは回帰テストとして機能しているため、できればそのままにしておきます。つまり、元のコードを作り直した今でもテストは機能します。
その後、抽出された機能に関する追加のテストを作成できます。この時点で、特定/リファクタリングした統合レイヤーを介してではなく、抽出された機能を直接テストするために、より複雑なテストを作成することが理にかなっている可能性があります。
于 2012-08-10T10:46:05.340 に答える
1
そこに特効薬の答えはないと思います。あなたが説明したことだけに基づいて、私は次のようになりたいと思います：
- 既存のテストはそのままにしておきます
- 抽出された依存関係専用の新しいテストを追加します
テスト コードを完全に複製することになる場合は、軽減したいと思うかもしれませんが、「完全に統合された機能」が意図したとおりに機能することをテストし続けることが重要です。
于 2012-08-10T10:51:02.280 に答える
0
依存関係への抽出は、おそらくリファクタリングです。全体的な動作は同じままであり、より多くのクラスに展開するだけです。リファクタリングは、TDD サイクルの 3 番目で最後のステップであり、新しいテストを追加することなく、テストがグリーンになった直後に行われます。だからここに私がすることです：
- すべてのテストが緑色の状態から始めます。
- Class1 から Class2 への動作 B を抽出します。
- 壊れたテストを確認します。何もない場合は、B をテストするのを忘れたか、リファクタリング ツールに超能力があるかのどちらかです。
- Class1 ではなく Class2 で動作するように、動作 B をテストする単体テストを修正します。
- (オプション) Class1 が Class2 と正しく通信すること、およびその逆の通信を検証するコラボレーション テストを作成します。そのためにモックやスタブを使用したい場合があります。
于 2012-08-10T20:24:46.137 に答える
0
refactorのフェーズでは、Test Driven Developmentビジネス コードまたは対応するテストのリファクタリングである可能性があります。そのため、コードをリファクタリングしている間に、テスト ケースもリファクタリングして合格するように対策を講じる必要があります。
于 2012-08-10T10:46:09.113 に答える