3

ユニットテストは初めてです。その原理は理解しましたが、それでも現在のプロジェクトをテストする方法がわかりません。java.nio.SocketChannelで動作するvoidメソッドをテストする必要があります。これらのメソッドは次のとおり
です。--initSelector、セレクターを開き、新しいServerSocketChannelをバインドして登録します--read、
データを読み取り、キューに入れます（そのデータが実際にキューに存在するかどうかを確認するための追加のメソッドを作成する必要がありますか？場合、そのメソッドのテストを作成する必要がありますか？）
-キューからデータを取得してSocketChannelに書き込むwriteメソッド

IOExceptionをスローしないようにこのメソッドをテストできますが、他に何がありますか？
そして、スレッドのrun（）メソッドをどのようにテストする必要がありますか？それとも、単体テストではなく、システムまたはその他ですか？

4

3 に答える 3

2

最初に、SocketChannel単体テストで実数を使用している場合、それは単体テストではありません。にはモック (を考慮Mockito) を使用する必要がありますSocketChannel。これにより、制御されたバイト ストリームをテスト対象のメソッドに提供し、どのバイトがチャネルに渡されるかを確認できます。

クラスが のインスタンスを作成している場合は、SocketChannelを受け入れるようにクラスを変更することを検討してSocketChannelFactoryください。SocketChannelFactory次に、モックを返すモックを注入できますSocketChannel。

run()単体テストで直接呼び出すことができます。

モッキートリンク

于 2012-04-11T10:35:29.447 に答える
2

基本的に、次の 2 つの可能性があります。

  • これらのメソッドを徹底的に単体テストしたい場合は、具象 (ソケットなどのハードウェア依存コンポーネント) をモック可能なインターフェイスの背後に隠し、単体テストでモックを使用して、予想されるパラメーターで予想される呼び出しがこれらのオブジェクトに対して行われることを確認する必要があります。
  • または、コンポーネント/アプリ全体で実際のソケットを使用して統合/システム テストを記述し、正しいソケットが開いていること、データが適切に転送されていることなどを確認できます。

理想的には、両方を実行する必要がありますが、実際には、単体テストが常に実行できるとは限りません。特に、ソケット、DB、ファイル システムなどの外部ソフトウェア/ハードウェア コンポーネントに依存するこのような低レベルのメソッドの場合、最善のアプローチは、これらのメソッド/レイヤーにロジックをできるだけ残さないことです (したがって、失敗の可能性はほとんどありません)。可能であり、ロジックを上位層に抽象化して、単体テストが可能なように設計されています (上記のモック可能なインターフェイスを使用)。

run()スレッドをテストするには、通常どおり単体テストからスレッドをテストできます。次に、スレッドによって生成された結果を取得して検証する前に、しばらく待つ必要がある可能性があります。

繰り返しになりますが、タスクの実際のロジックを aCallableや などに抽象化するRunnableと、単体での単体テストがはるかに簡単になります。また、これによりExecutor フレームワーク(現在または将来) を使用できるようになり、並行処理をより簡単かつ安全に処理できるようになります。

于 2012-04-11T10:39:15.720 に答える
0

run（）は他のメソッドと同じであるため、単体テストから呼び出すことができるはずです（もちろん、無限ループで実行されているかどうかによって異なります。run（）が呼び出しているメソッドをテストすることをお勧めします。 ）。
SocketChannelの場合、SocketChannel自体をテストしたくないと思います。特定の開始条件のセットを指定して、コードがSocketChannelとどのように相互作用するかをテストする必要があります。
そのため、モックを作成して、コードにモックと通信させることを検討できます。これにより、コードが期待どおりにチャネルと相互作用しているかどうかを確認できます（read（）、write（）など）。たとえば、http：//code.google.com/p/powermock/
を チェックしてください。

于 2012-04-11T10:41:15.203 に答える