2

私はこの方法を持っています：

public bool CanExecute()

そして70回のコミットの後、追加のパラメーターを追加しました

public bool CanExecute(IStation target)

ここで問題となるのは、さまざまなnull/プロパティの組み合わせをテストするこのCanExecuteメソッドをカバーする7つの単体テストがあることです。

この単純なパラメーターを追加するには、これらの7つの単体テストを修正する必要がありました。修正は簡単ですが...

単体テストを更新するために必要なこの種の手動リファクタリングを回避するためのベストプラクティスやパターンはありますか？

近い将来、追加のパラメーターが追加される可能性があることがわかっている場合、それを説明するために単体テストをどのようにコーディングしますか？それは単にやり過ぎですか、それとも従うべきイディオム/パターン/何かがありますか？

編集： IStationの依存関係はオプションではないため、単純にオーバーロードを追加することはできませんでした。IStationインスタンスが予期されていたが、何も利用できなかったため、CanExecuteを介して提供する必要があるバグを修正していました...ご覧のとおり。

リファクタリングツールがその方法のようです。ありがとう！

4

4 に答える 4

9

コードに両方のメソッドを保持できませんか？IStationパラメータがnull以外であることが必須でない限り、既存のコードを変更せずにそれを回避することができます。

あるいは、パラメーターに適切なデフォルトがある場合（これもnullのように！）、resharperはこのような変更を非常に簡単に処理できます。新しいパラメータを追加するには、関数名を右クリックして[署名の変更...]を選択します。ここから、適切なデフォルトで新しいパラメータを追加できます。RSはすべての呼び出しを更新するので、更新する必要はありません。

于 2008-12-20T17:06:38.360 に答える
1

もちろん、単体テスト全体で重複している機能が多すぎるかどうかを考慮する必要がありますが、常にそうであるとは限りません。

かなりの数の最新のIDE（C＃用のリシャーパー）は、新しいパラメーターのデフォルト値を提供できる「メソッドの変更」リファクタリングをサポートしています。このリファクタリング機能は、マスターにとって本当にやりがいのあるものだと思います。

于 2008-12-20T17:08:44.737 に答える
1

メソッドが再び変更される可能性があることがわかっている場合は、古い単体テストを変更するのではなく、メソッドをオーバーロードして、オーバーロードされたメンバーの単体テストを追加するのが賢明だと思います。星が揃っている場合は、オーバーロードされたメソッドが元のno-argメソッドを呼び出すことに気付くかもしれません。そのため、新しいパラメーターのテストを作成するだけで、元の7つのテストを繰り返す必要はありません。

于 2008-12-20T17:30:58.810 に答える
0

私は両方を保持します。メソッドをオーバーロードし、オーバーロードされた新しいメソッドの単体テストを追加して、追加したばかりのものをカバーします。

于 2008-12-20T19:34:53.240 に答える