1

(MVC とは対照的に) Delegate-Model 設計に出くわしたばかりで、それを試してみたいと思っています。また、最近 GOOS スタイルで TDD 開発を学んでいます。だから私は私のウォーキングスケルトンテストを次のようにしたいと思っています: (私はJUnitを使用しています)

@Test
public void userGeneratesEvent_DNotifiesM_MNotifiesDOfUpdatedData_DGetsNewDataFromM() {
    Model model = new Model();
    Delegate delegate = new Delegate(model);
    model.addListener(delegate);
    // Not sure how to "generate the user event" here
    assert( ... );
}

上記のコメントのように、私の問題は、デリゲート内からユーザー イベントを適切に生成する方法がわからないことです。たぶん、デザイン パターンがどのように機能するかについての私の理解は外れているかもしれませんが、デリゲートはビューとコントローラーの両方をカプセル化する必要があります。 "?

ご意見やアドバイスをいただければ幸いです。

4

1 に答える 1

1

ウォーキング スケルトン テストは、できる限りエンドツーエンドに近づける必要があります。可能であれば、テストは GUI から Web サービスまたはデータベース レイヤーに至るまで行う必要があります。これにより、すべてが適切に接続できることが検証され、デプロイを自動化して本番環境で実行できます。

ただし、実際の Web サービスやデータベースを使用したテストは、自動化するには遅すぎたり脆弱であったりする場合があります。この場合、依存性注入を使用して、これらのレイヤーのすぐ下でテストします。

GUI をテストするには、GUI テスト フレームワークを使用して、GUI 自体をテストできます (これは、GOOS で行ったことです)。Swing を使用している場合は、FESTをお勧めします。より信頼性が高く、迅速な受け入れテストを可能にする別のアプローチは、GUI レイヤーのすぐ下でテストすることです。ただし、このためには、Delegate-Model の代わりに MVP または MVVM を使用する必要があります

ユーザーイベントをプログラムで適切に発生させる方法にまだ行き詰まっています。たとえば、ユーザーが UI を介してテーブルに行を追加し、最後にモデル内の行数が 1 であることをアサートします。これを行うには、デリゲートのカプセル化を解除する必要がありますか?

カプセル化を解除するか、ビューの下でテストできるようにする MVP/MVVM などのパターンを使用するか、FEST を使用して GUI 経由でテストする必要があります。FEST を使用してコンポーネントを自動的にクリックし、JTable に指定された行数があることを確認してイベントを発生させることをお勧めします。FEST テストは遅いですが、かなり信頼できるので、それを使って単体テストを書くべきではありません。

アプリケーションが適切なサイズ (> 3000 LOC) に成長した場合は、MVP/MVVM へのリファクタリングを検討できます。これは、複雑さを正当化するために、コードの再利用と高速で信頼性の高いエンド ツー エンド テストから十分なメリットが得られるためです。FEST テストと単体テスト (モデル上) は、このリファクタリング中に壊れてはならず、安全にリファクタリングするのに役立ちます。プレゼンター/ビューモデルが別のクラスの場合、それらのユーザー イベントを直接呼び出して、追加のテーブル行が追加されたことを (モックで) 検証/アサートできます。

于 2012-06-05T19:51:59.497 に答える