6

階層化されたアーキテクチャを持つエンタープライズ アプリケーションに TDD を適用する方法は?

以下のアプリケーションにTDDを適用する方法を知りたい

  1. WPF アプリケーション (6 ～ 7 画面)
  2. 3-4 モジュール（プリズムモジュール）
  3. 一部のアプリケーション サービス (ロギング、例外処理、セキュリティ、承認、コア ビジネス サービス ライブラリ)
  4. データ アクセス層 (Entity Framework を使用)
  5. 一連の WCF サービス

私が理解しているように、最初のことはアーキテクチャを正しくすることです。その結果、コンポーネントが識別されます。次は、コンポーネントを個別に開発することです。

TDD では、(コンポーネントの) 設計は時間とともに進化します。次のコンポーネントの場合、TDDを使用する方法は（私が認識しています）です

  1. すべてのユースケースを特定する
  2. すべてのテスト ケースを特定する
  3. テスト ケースごとにすべてのシナリオを記述し、シナリオごとに失敗するテスト ケースを記述します。テスト ケースに合格するように、小さなコードを作成します。新しいシナリオが見つかった場合、リストに追加
  4. すべてのテスト ケース (すべてのシナリオに対応) がパスするまで、Red-Green-Refactor に従います。
  5. リファクタリングでは、DRY、YAGNI、Mocking、DI などを忘れないでください。
  6. 最終結果は適切に設計されたコンポーネントです (どれだけ適切に設計されているかは、開発者の経験とスキルに依存します)。

私が直面している問題は、コンポーネントの場合、TDD プロセスのステップ 6 に到達するまで、インターフェイスがわからないことです。複数のコンポーネント、複数のチームがあるため、彼らが何を思いつくかは誰にもわかりません。

上記のシナリオに基づく要約の質問

  1. 欠けている基本はありますか？はいの場合は、適切なリソースを教えてください。
  2. レイヤード アーキテクチャに TDD を適用する方法は?
  3. 複数のコンポーネントを並行して開発する方法
  4. WPF UI (PRISM) を使用した TDD のベスト プラクティス
  5. データベースを使用した TDD のベスト プラクティス (Entity Framework を使用)
  6. TDDを使用する場合、WCFサービス契約を決定する方法は?
4

2 に答える 2

1

順番が間違っていると思います。アーキテクチャを選択してから、TDD でそこにたどり着こうとしています。TDD の背後にある考え方は、何もないところから始めて、必要に応じて階層化されたアーキテクチャにたどり着くことです。

もちろん、非常に大規模なプロジェクトを検討している場合、それはおそらく役に立たないでしょう。私の通常のアプローチは、作業を (プログラマーではなく) 実際の人にとって意味のあるものに分割しようとすることです。いいえ、完全なドメイン駆動設計について話しているわけではありません。私は部外者がするように、さまざまな部分について考えているだけだと言っています。

たとえば、キャッシュ レジスター (お金を入れて合計金額を計算できるもの) を表すプログラムを作成したいとします。

私が最初にやりたいことは何ですか？お金を保持して分配します。だから、引き出しが必要です（最初のコンポーネント、チームに渡します）。それを開くためのボタンが必要です (2 番目のコンポーネント、2 番目のチーム) など... 重要なのは、どのように行うかではなく、何を行うかに焦点を当てることです。

はい、行わなければならない契約/プロトコルの話し合いがたくさんあります。これらは、関係するチームが問題に直面したときに解決しなければならないことです。重要なのは、自分がやりたいことに集中することです。今の問題を解いてください。事前に最適化しないでください。すべてのコンポーネントがすべてのレイヤーを必要とするわけではないことに気付くでしょう。

ベスト プラクティスの質問に対する簡単な答えは、「場合による」です。(安っぽく、一般的で、使い古された IT の答えです。) 一般的なルールは、実装ではなく動作に集中することです。テストが信頼できることを確認してください (常に正しい結果が得られます)。可能な限りテストしてください...または、番号を付けて...

  1. 設計ではなく、テストから始めます。Roy Osherove や他の人たちは、このテーマについてたくさんの著作を持っています。彼の本は、Micheal Feathers とともに、始めるのに最適な場所です。
  2. テストから始めて、より多くのテストを実行するにつれてレイヤーが進化すると、レイヤード アーキテクチャ上の TDD に行き着きます。
  3. 意味のある方法でそれらを分割します。私のルールは、現実世界で理にかなっていることに固執することです。エンジンチームはエンジンを手に入れ、タイヤチームはタイヤを手に入れます。人々がコミュニケーションをとることを確認してください。
  4. PRISMは使っていません。
  5. 私は EF を使用していませんが、データベースのテストはワームの缶詰であると言えます。統合テストには、多くの環境設定などが含まれます。Ayende には、これに関するかなりの数のブログ記事があります。
  6. デンジャー・ウィル・ロビンソン. WCF サービス契約が必要だと確信できる理由は何ですか?

これが本当に漠然としていたら申し訳ありません。私がドロップした名前をグーグルで検索してください。始めるのに適した場所です。TDD を強化したい場合は、経験豊富なコーダーを何人か雇って、ペア プログラミングを使用してください。余裕がない場合は、誰かを雇ってトレーニングを行ってもらい、その後ペア プログラミングを行います。それができない？いくつかの本を入手して、ペアプログラミングを使用してください。

次に、ペアを打ち負かして、最初にテストを書いていることを確認します。

結局のところ、何をしたいかを決定し、テストによってアーキテクチャを進化させることが重要です。その逆ではありません。

于 2012-12-19T18:37:44.133 に答える
1

これまでの計画はすべて正しい方向に進んでいると思います。私がアドバイスするのは、事前の設計に十分な時間を費やして、各レイヤー間のインターフェースを定義できるようにすることです。それなしで開発を始めることは (TDD は言うまでもなく) 現実的ではありません。すべてのチームがインターフェースについて合意したら、モック オブジェクトを使用してインターフェースを実装することで、TDD に簡単に移行できます。Rhino Mocks など、十分に確立されたモッキング フレームワークが多数あります。事前にインターフェイスを作成するという考えは、言うは易く行うは難しであり、間違いなく途中で変更を加えなければならないことになります。しかし、出発点が必要です。これは一種の課題であり、まさにコンポーネント モデル図が役立つ場所です。チームが協力してこれを事前に作成することにより、

また、データベース層にも特別な配慮をいたします。これは、別の議論に値する議論の余地のあるトピックです。EF を使用すると、レイヤー全体を単純に「モックアウト」できないことがわかります。そのためには、EF の TOP にまったく別の抽象化を作成する必要があります。これを行うと、アプリケーションが不要に複雑になる可能性があります。これが必要な場合は、非常に慎重に検討する必要があります。テスト データベースにテスト データを入力するだけでよいのであれば、自動テストでデータベースを直接呼び出さない理由はありません。

于 2012-12-19T19:22:13.267 に答える