3

Web およびデスクトップ インターフェイスを必要とするプロジェクトを開始します。解決策の 1 つは IdeaBlade ( http://www.ideablade.com ) のようです。それを使用する人は、その制限と利点を説明できますか? テスト可能ですか？

ありがとう、アレックス

4

1 に答える 1

6

IdeaBlade の技術担当副社長として、この分野における DevForce の制限と利点について一般的にコメントするつもりはありません。ただし、具体的な質問には喜んでお答えします。

テスト可能ですか？これに対して、私は答えの始まりで答えることができます。

それは潜在的に論争の的となる質問です。人々は、何かをテスト可能にするものについて強い感情を持っています。特定のテストシナリオに限定させてください..そして、私たちがあなたのテスト要件をどの程度満たしているかを判断してください.

1) 好みに応じて、DevForce は純粋な POCO エンティティをサポートします。ほとんどの人は、基本の Entity クラスから派生したエンティティを使用することを好むので、以降の説明はそのようなエンティティに完全に限定します。

2) 任意の ctor を使用してそのようなエンティティを新規作成し、他の設定なしでその (非ナビゲーション) プロパティを取得および設定できます。

var cust = new Customer {ID=..., Name =...}; // have fun

もちろん、アセンブリ参照は必要です。

3) そのナビゲーション プロパティ (他のエンティティを返すプロパティ) をテストするには、最初に EntityManager (作業単位、コンテキストのようなコンテナー) を新規作成し、エンティティを EM に追加またはアタッチしてから始めます。基本クラスから継承するエンティティのナビゲーション プロパティは、そのコンテナを介して関連するエンティティを見つけることを想定しています。

4) ほとんどの自動化されたテストでは、EntityManager は切断された状態で作成されるため、サーバーまたはデータベースにアクセスしようとしません。

Order、Customer、いくつかの OrderDetails を追加できます。それらはすべてテストのコンテキスト内で構築されていることに注意してください...どこからも取得されません。

次に、order.Customer がテスト Customer を返します。order.OrderDetails はテストの詳細を返します。準備は、テスト エンティティである EM を作成し、これらのエンティティが一意の ID を持ち、関連付けられていることを確認することから成ります。

シーケンスの例を次に示します。

var mgr = new EntityManager(false); // create disconnected

var order = new Order {ID = ..., Quantity = 1, ...};

var customer = new Customer {ID = 42, Name = "ABC", };

mgr.AttachEntity(order);

mgr.AttachEntity(customer);

order.Customer = customer; // associate them

EM はインメモリ データベースとして機能します。

5) LINQ を使用できるようになりました

var custs = mgr.Customers.Where(c => c.Name.StartsWith("A").ToList();

var orders = mgr.Orders.Where(o => o.Customer.Name.StartsWith("A")).ToList();

6) もちろん、クロステスト汚染を排除するために、各テストの前に常に新しい EntityManager を作成します。

7) 私はよく、いわゆる「データ母」テスト ヘルパー クラスを作成して、逸脱したケースを含む標準的なテスト データのコレクションを EM に入力します。

8) EntityManager のテスト エンティティのキ​​ャッシュをファイルまたはテスト プロジェクト リソースにエクスポートできます。テストが実行されると、DataMother はこれらのテスト エンティティを取得および復元できます。

単体テストから徐々に統合テストに移行していることに注意してください。しかし、(これまでのところ) 私のテストでは、サーバー、Entity Framework、またはデータベースへのアクセスは必要ありません。それらは高速で実行され、気が散るセットアップの失敗に対して脆弱ではありません。

もちろん、深い統合テストでサーバーにアクセスでき、ローカル、LAN、および Web のシナリオでサーバーとデータベースを動的に簡単に切り替えることができます。

9) 対話テストのために、クエリ、保存、変更、追加、削除、およびその他のイベントをインターセプトできます。

10) 私が説明したことはすべて、通常の .NET と Silverlight の両方で機能し、私が遭遇したすべてのテスト フレームワークで機能します。

マイナス面として、私は私たちの製品をモックフレンドリーとは言いません.

私たちは持続性を知らない (PI) ではないことを認めます。あなたが PI 狂信者なら、私たちはあなたにとって間違った選択です。

私たちは PI の重要な利点を理解し、製品でそれらを実現するために最善を尽くします。私たちは、フレームワークの懸念を見えなくするためにできることを行います。それでも、ご覧のとおり、いくつかの場所で抽象化が漏れています。たとえば、次のメンバーをエンティティのパブリック API に追加します。

  • EntityAspect (持続性認識へのゲートウェイ)
  • エラー変更
  • PendingEntityResolved
  • プロパティが変更されました
  • ToQuery<>

個人的には、これを 2 つ (EntityAspect、PropertyChanged) に減らします。他の人は私に忍び寄りました。価値があるのは、 Object から継承すると (必要に応じて)、別の余分な 5 が発生することです。

純粋な PI と開発の容易さの間で適切なトレードオフを行ったと感じています。

私の質問は、「多くの摩擦なしに期待を検証するために必要なものを提供します...ユニットから深い統合テストまでの全スペクトルに沿って?」

同様の製品との摩擦を減らして同様の機能を得る方法を知りたいと思っています. また、アプリケーション テストのサポートを改善する方法について提案をお待ちしております。

私が見落としている可能性のある他のテスト シナリオについて、お気軽にご質問ください。

お役に立てれば

区

于 2010-04-29T01:37:05.863 に答える