2

コードの一部をテストするためにプライベート アクセサーを使用する場合、不利な点はありますか?

パブリックに公開されているメソッド/プロパティとは対照的に、GUI をテストするためだけにプライベート アクセサーを使用するオプションを検討しています。

これにより、必要ないくつかの GUI テストが可能になります。私は、プライベート アクセサーの動作に隠された「落とし穴」がないことを確認したかっただけです。

4

3 に答える 3

1

それらを使用しないことをお勧めします。代わりに、依存関係を注入できるかどうかを確認してください。プライベート アクセサーを使用していくつかの単体テストを作成するレガシー コードに取り組んでいる場合を除き、それらを使用しないことをお勧めします。この場合でも、レガシー コードをリファクタリングするまで一時的にそれを行うことをお勧めします。

于 2012-12-07T20:49:00.993 に答える
1

要約すると、あなたが述べた目標は次のとおりです。

GUI をテストするためだけにプライベート アクセサーを使用するオプションを検討しています...これにより、必要な GUI テストが可能になります...

要するに、はい、落とし穴があります。テストしているコードは、依然としてユーザー インターフェイスに密接に結合されています。

コメントでは、目標/問題を次のように明確にします。

テストしたい場合は、ドラッグ/ドロップしてください。カスタム コントロール、オーバーライドされたイベント?

私が言えることは、ようこそご乗船ください。ソフトウェア業界は、半世紀近くにわたってこの問題に取り組んできました。UI のテストが難しいという事実は変わりません。本当に難しいです。はい、UI 要素と密接に結合されたコードの一部を取得して、自動化を試みることができます。ただし、不十分な仮定に対して前進するために歯と爪と戦うことになります。

UI をテスト可能にする「コツ」は、UI をテスト可能にすることではなく、テストしたいコードを UI から削除することです。したがって、MVC、MVVM などの N 層アプリケーション開発およびプレゼンテーション デザイン パターンが広く受け入れられています。

以下を参照してください。

これらのデザイン パターンの多くの背後にある主な目標または原動力は、動作と表示の間の密接な結合を取り除くことです。これにより、ユーザー インターフェイスなしでドラッグ アンド ドロップなどの動作をテストできます。パターンを確認し、好きなパターンを選択してから、単体テストを作成しながらコードのリファクタリングを開始することをお勧めします。

テスト用の UI を記述するもう 1 つの方法は、if、else、for、while、switch、またはその他の制御ステートメントをユーザー インターフェイス コードからすべて削除することです。結果として得られる UI の「シェル」は、変更に対して非常に回復力があるはずです。リフレクションに依存するデータ バインディングなどを使用する場合は注意が必要です (これは一般的に許容される方法です)。これの主な欠点は、コンパイラがメンバーが存在しないことを通知できないことです。

更新しました

@ティミーあなたが書いた：

...たとえば、マウスのクリック動作をテストしたい場合...

では、フォームに埋め込むのではなく、コントローラーに移動できないマウス クリックの動作についてはどうでしょうか。「閉じる」ボタンに問題があると思いますが、それ以上にロジックを別のクラスに移動してテストできるようにしてみませんか?

ところで、MVC、MVVM などのパターンを 1 つだけ選択する必要はありません。それらは「ガイドライン」または「提案」であり、厳密なルールではないため、ばかげてはいけません。ロジックを UI から分離し、独立してテストできるようにしてください。例として、「クリック」イベントは単純なコマンド クラスに適しているでしょうか? コマンド パターンを使用するのは簡単で、オブジェクトを新規作成して実行します。フォルダー コピー フォームの次のコード例を考えてみましょう。

private void OnCopyClick(object sender, EventArgs args)
{
    var cmd = new MyCopyCommand(this.FolderPath, this.txtTargetFolderPath.Text);
    new ErrorHandler(this).Perform(cmd);
}

これはうまく機能します。コマンドを提供する以外に「実際の」ロジックはなく、条件付きコード パスもありません。コマンドを直接呼び出すのではなく、エラーを適切に処理できる人に委ねることに注意してください。通常、この「ErrorHandler」は、直接構築するのではなく、フォームに提供されますが、アイデアは得られます。

これから、MyCopyCommand の正しい動作を簡単に確認できるはずです。最終的には、UI に一連の「フラットな機能」を配置する必要があります。入れ子または中括弧を持たない関数。もちろん、これは経験則であり、生産性を妨げるほど極端に取られるべきではありません。

これは大変な作業のように思えるかもしれませんが、実際には、一連のテストを作成する作業を既に行っている場合はそうではありません。生産性が高く、堅実なコードを書くことができます。いつチートをするか、いつチートをしないかを知る必要があります。それには経験が伴います。20 年後、そのうち 10 人が NUnit を書いていますが、私はまだ時々失敗します。これをしなかったために何かが壊れた場合は、まず UI からロジックを抽出し、それが壊れていることを証明する単体テストを作成してから修正します。

于 2012-12-10T22:16:26.907 に答える
0

AD.NETが言ったことに加えて。これらのプライベート プロパティは、リファクタリング (モデル ビュー コントローラー、モデル ビュー プレゼンター、モデル ビュー ビューモデル) が完了するまでテストでのみ使用できるため、GUI をまったくテストする必要はありません。

于 2012-12-07T20:54:29.257 に答える