1

私は、それぞれ独自の通信スレッドを持つプレーヤーオブジェクトとして表される複数の「プレーヤー」へのネットワーク通信を備えたSwing Javaアプリケーションを持っています。アプリには、すべてのプレーヤー オブジェクトを管理する「チーム」オブジェクトがあります。いくつかの UI コンポーネントは、Team オブジェクトを通じてプレイヤーから渡されたイベントをリッスンします。

私の設計では、チーム オブジェクトは、invokeLater を使用して Swing スレッドですべてのイベントを起動するため、アプリケーションの残りの部分でスレッド化の問題を気にする必要はありません。ただし、JUnit テストで Team クラスをテストする方法がわかりません。

もう少し背景。最初に、Team オブジェクトにプレイヤー オブジェクト スレッドでイベントを発生させました (スレッドの切り替えはまったくありません)。チーム単体テストは成功しましたが、invokeLaters を使用して UI で多くのスレッドの問題が発生し、すべての場所で同期されました。次に、Team オブジェクトが Swing スレッドでイベントを発生させることで、スレッド モデルを簡素化することにしましたが、イベントを受信しないため、チームの単体テストは失敗します。何をすべきか？

心に浮かぶ解決策は、チームの上に追加のオブジェクトを導入してスレッドの切り替えを行い、元の単体テストをそのまま維持することですが、単体テストを成功させるためだけに運用コードを複雑にするという考えは好きではありません。

4

3 に答える 3

4

で JUnit テストを行ったときEventQueue.invokeLater、私はその邪悪な静的要素から切り離されました。invokeLaterメソッドとインターフェイスを作成しますisDispatchThread。本番環境では、実装は に転送するだけですEventQueue。テストには、独自のスレッドを使用します (テストごとにセットアップおよび破棄できます)。

その他のランダムなアドバイス:

  • GUI はできるだけ薄くしてください。
  • 他のすべてのものからスレッド化を維持し、他のすべてのものをスレッド化しないでください。
  • スレッドセーフであると主張するものには疑いを持ってください。
于 2008-11-30T21:23:30.603 に答える
2

頭に浮かぶ解決策は、スレッドの切り替えを行い、元の単体テストをそのまま維持する追加のオブジェクトをTeamの上に導入することですが、単体テストを成功させるためだけに本番コードに複雑さを導入するという考えは好きではありません。

これがここに当てはまるかどうかはわかりませんが、私が追加している「複雑さ」は、実際にはコードを改善するより高いレベルの抽象化であることがよくあります。

モックオブジェクトの背後にある元々のアイデアは、単体テストを簡単にすることではなく、APIのレベルで作業するのではなく、ユビキタス言語で抽象化を表すインターフェイスを作成する「インターフェイスの発見」でした。

于 2008-11-30T22:05:46.163 に答える
2

easymock を使用して、テストするクラスを分離し、モック オブジェクトにイベントを受け取って、イベントが発生したことを確認させることができます。

EasyMock をお勧めします: http://www.easymock.org/

あなたの話から、ユニットテストはより統合テストであり、非常に複雑であると感じます。その場合は、単純化して分離してみてください。おそらくhttp://junit.sourceforge.net/doc/testinfected/testing.htmを読んだことがあるでしょう

これが役立つことを願っています。

于 2008-11-30T20:55:49.783 に答える