0

私は基本的に、クライアントとサーバー (必ずしも HTTP サーバーではない) を構築することにより、Java ソケット プログラミングを練習しています。簡単に言えば、クライアントはソケットを介してサーバーにリクエストを送信し、サーバーはリクエストをタスクキューに追加します。スレッド プールには最初に特定の数のスレッドがあり、空いている各スレッドはタスク キュー内の 1 つの実行可能なタスクに割り当てられます。私の Web サーバーには、ディスクのファイルからデータを保存および取得する単純なストレージもあります。このプロジェクトでは、いくつかの並行性の問題に対処する必要があります。

基本的に、クライアント、サーバー、スレッド プール、ハンドラー、ストレージを構築する必要があります。ただし、体系的にしっかりとテストしたい（単体テスト、結合テストなど）。テストの経験があまりないので、ポインター、方法論、フレームワーク、またはチュートリアルを探しています。(私は Ant を使用してビルドを自動化し、最初はテスト用に JUnit と EasyMock を検討しています)

建築

4

1 に答える 1

0

テストの前に、ラフで準備の整ったプロトタイプ コードをコーディングすることから始めます。動作を確認し、これから使用する API の感触を掴むためです。

次に、JUnit を使用したいくつかの単体テストを紹介します (他のフレームワークもありますが、JUnit はどこにでもあり、開始するためのチュートリアルがたくさんあります)。

オブジェクトがタスクを完了するために他のオブジェクトとやり取りする必要がある場合は、モック (EasyMock など) を使用してやり取りを提供します。

満足したら、オブジェクトがどのように相互作用するかのテストを開始できます。モックを本物に置き換える新しい (統合) テストを作成できます。相互作用が大きくなると、複雑さが増します。

覚えておくべきこと

  • 単純なメソッドはテストする価値がありません (例: 単純なアクセサー)
  • 100% のカバレッジは時間の無駄です
  • どんなテストも、何もないよりはましだ
  • 単体テストは統合テストより達成しやすい
  • すべてのテストが機能するわけではありません
  • マルチスレッド アプリケーションのテストは難しい

Google がテストを行う方法に関する本があります。基本的に、彼らは何かが実行可能になるまでテストを書きません。彼らには、テスト用にコードを構造化する方法についてアドバイスするエンジニアがいます。ポイントは：

  • 実行可能なコードが目標
  • テストはその目標に追加されますが、それを置き換えるものではありません
  • テスト可能なコードを書くことは習得したスキルです
于 2012-11-03T06:09:13.760 に答える