問題タブ [testability]

TL; DR： MVVMクライアントでViewModelsとWCFサービス間の依存関係を実装するための優れたテスト可能な方法は何ですか？

これを実行しようとしたときに発生した問題の詳細については、残りの質問をお読みください。

wcfサービスに接続するSilverlightクライアントに取り組んでおり、クライアントの単体テストを作成したいと考えています。そのため、ViewModelsでwcfクライアントを使用し、その相互作用をテストするための優れたソリューションを探しています。私はこれまでに2つの解決策を見つけました：

解決策1：これは実際に私が今までそれを実装した方法です：

良い部分：モックするのは比較的簡単です

悪い部分： 私のサービスクライアントは私のViewModelと同じくらい存続し、同時リクエストがある場合、どの回答がどのリクエストに属しているのかわかりません。

解決策2：この回答に触発された WCFサービスクライアントの存続期間。

良い部分：各リクエストは異なるクライアント上にあるため、リクエストと回答を一致させることに問題はありません。

悪い部分：テストするのはもっと難しいです。毎回、ファクトリとwcfクライアントの両方のモックを作成する必要があります。私はすでに200のテストを持っているので、これは私がやりたいことではありません... :(

だから私の質問は、どうやってやるの？ViewModelsはwcfサービスとどのように通信し、依存関係をどこに挿入し、その相互作用をどのようにテストしますか？何かが足りないと感じます。

静的クラスとインスタンス クラスをテストする際の問題を説明する例を探しています。誰かがそれを提供できますか？

私はオブジェクト指向デザインの問題に取り組んでいます。コードを提供するのではなく、混乱している部分に焦点を当てて、テキストで説明しようと思います。

TaxPolicyのリストを含むSalesPolicyというクラスがあります。TaxPolicyは、名前と税率を属性として持つ税政策を表す抽象クラスです。TaxPolicyには、acceptという抽象的なメソッドが含まれています。TaxPolicyの具体的な実装では、acceptメソッドを実装し、TaxPolicyをいつ適用できるかを決定するためのロジックを提供する必要があります。

SalesEngineという別のクラスがあります。SalesEngineにはSalesPolicyがあり、SalesPolicyはSalesEngineコンストラクターのパラメーターの1つです。SalesEngineは、acceptメソッドを呼び出して、SalesPolicyのTaxPolicyのリストからTaxPolicyをアイテムに適用できるかどうかを判断し、それに応じて税金を計算します。前に説明したように、SalesPolicyには、TaxPolicyのリストとリストに追加するメソッドである単一の属性が含まれています。

私が知る必要があるのは、SalesEngineクラスにSalesPolicyのようなパラメーターを設定してもよいかどうかです。テスト可能なコードの観点から、これはどのような影響を及ぼしますか？

そのようなことをするように見えるコードを書かなければなりません (もちろんもっと複雑です):

私の質問は次のとおりです。そのようなコードをテスト可能にする手法はありますか? 次のようなテストを書くとは思わない：

最高のアイデアです。システム関数を呼び出さずに stopThread() 関数をテストする方法は? pthread_create をモックする方法はありますか?

私はアプリケーションの単体テストを行っており、それらをさらに改善/追加しています。私は単体テスト/テスト駆動開発の初心者であり、テストしたい次の方法を見つけました。私は立ち往生しています。私の質問は、テスト可能になるようにこれを書き直す方法があるかどうかです。

私がこの質問をするのは、彼らが非常に正当な理由でそれを行ったと信じており、ほとんどの人がそれを適切に使用していないと信じているからです.とにかく、これまでの業界での私の経験から. しかし、私の理論が本当なら、なぜプライベートアクセス修飾子が含まれているのかわかりません...?

デフォルト アクセスを適切に使用すれば、カプセル化を維持しながらテスト容易性が向上すると思います。また、プライベート アクセス修飾子が冗長になります。

デフォルトのアクセス修飾子を使用して、他の世界から隠す必要があるメソッドに一意のパッケージを使用することで、同じ効果を提供できます。テスト容易性を損なうことなくこれを行います。ソース フォルダーで宣言されているすべての既定のメソッドにアクセスできます。

これが、Javaがパッケージアクセスを「デフォルト」として使用する理由だと思います。しかし、プライベートアクセスも含まれている理由はわかりません。有効なユースケースがあると確信しています...

私はテストの初心者です。アプリを開発するときは、アプリをテストするために Robotium を使用しますが、今度は Util クラスのメンバーであるいくつかの関数をテストしたいと思います。例えば：

または例：

これらの機能をテストするにはどうすればよいですか?

どうもありがとう！！

MVVM light toolkit を使用する WPF アプリケーションがあるとします。

このツールキットの良い例は Locator です。サービスを登録してインターフェイス駆動型にすることを可能にする SimpleIoC が含まれていることは素晴らしいことです。

Locator コンストラクターが実際に大きくなることがあります。残念ながら、インターフェースを登録する以外に、次のようなロジックが含まれています。

これは単なる例でした-ロケーターコンストラクター中にさらにロジックが必要な場合。サービス アーキテクチャが独立していないために間違って作成された可能性があります。または、そのような場合は、ロケータの使用を辞任する必要がありますが、そうすると DI が失われます。

もう 1 つのことは、いくつかの ViewModel に Locator.GetInstance への参照があることです。これは、テスト容易性を有効にするためにコンストラクターを介して注入する必要があるため、別の良い方法ではありません。

もう 1 つの側面は、AvalonDock で正しく使用することです。

AvalonDock は、アンカー可能でドッキング可能なペインを備えた Visual Studio などのアプリに似たアプリを準備できる、優れたアンカー可能なコントロールです。

このペインは実際には、プロパティを介して AvalonDock にバインドされた別の ViewModel です。

MainViewModel にはプロパティ Tools = new Tools[] { ViewModel1, ViewModel2} があります

しかし、各 ViewModel は Locator に登録されていました。

したがって、MainViewModelでそれらを（DRYに違反して）使用しています

プロパティのゲッター: Locator.GetInstance()

私の意見では、これは別の悪い例です-安全ではありません. Avalon ツールの ViewModel1 が必要とするサービスがまだ登録されていないが、MainViewModel のインスタンス化中に getter を介して呼び出された場合はどうなるでしょうか。

ミスマッチになり始めました。何か良い練習はありますか？

Workspaces (MainViewModel) などの多くの例を見つけましたが、非常に便利な Locator を同時に使用している人は誰もいませんでした。

依存性注入とインターフェイス駆動のおかげで、mme がプロジェクトをテスト可能にするのは良いことだと思うので、Locator を維持したいと思います。

アイデアの提案はありますか？ありがたく思います。

私は Java で多くのコードを開発し、Groovy と Haskell に手を出しました。それが今では Scala につながっています。

私は Scala の機能面には比較的慣れていますが、Scala のオブジェクト指向設計については、特にトレイト/ミックスインが原因で、Java とは少し異なるように感じられるため、少し不安定です。

私はできる限りテストしやすいコードを書くことを目指しています。

• 可能な場合の不変性
• コンストラクターによる状態の注入を優先する
• 常に継承ではなく構成を使用してください ( SO に関するこの投稿の影響を強く受けており、おそらく過剰反応です) 。

今、私はこの新しい Scala テリトリーに足を踏み入れようとしていますが、ここでどのアプローチを採用すべきか、特に何らかの目的で継承を使用する必要があるかどうかを判断するのに苦労しています。

Programming Scala (Wampler and Payne; O'Reilly、第 2 版) には考慮事項のセクション (「優れたオブジェクト指向設計: 余談」) があり、SO に関する多くの投稿を読みましたが、見たことはありません。テスト容易性の設計上の考慮事項についての明示的な言及。この本は、継承の使用に関する次のアドバイスを提供しています。

1. 抽象基本クラスまたは特性は、ケース クラスを含む具象クラスによって 1 レベル サブクラス化されます。
2. 次の 2 つの場合を除いて、具象クラスはサブクラス化されません。
   • 特性で定義された他の動作を混在させるクラス (...)
   • 自動化されたユニットテストを促進するためのテスト専用バージョン。
3. サブクラス化が適切なアプローチのように思われる場合は、動作を特性に分割し、代わりにそれらの特性を混合することを検討してください。
4. 親子型の境界を越えて論理状態を分割しないでください。

SO を掘り下げてみると、ミックスインが合成よりも望ましい場合があることも示唆されています。

本質的に、私は2つの質問があります：

1. テスト容易性を考慮しても、継承を使用した方がよい一般的なケースはありますか?

2. ミックスインは、コードのテスト容易性を向上させる良い方法を提供しますか?