エピソード：ポーカー。
ある命令で、遅滞なく、数千のクローンが狭いネットワークの廊下を駆け巡り、敗北の疑いや恐れを知らなかった！ 決闘で会って勝つために！ クローンは、ほとんどの場合マスターではなく、勝つようにプログラムされていますが、成功した場合は目標に導く指示を明確に守ってください。 ルールは誰にとっても同じであり、それぞれ自分自身のためですが、この混乱に陥っている人を生き残り、倒すチャンスは一度もありません...
これは、伝説的なスターウォーズの物語のエピソードではなく、幻想的な小説のプレビューでもありません。 これは、ソーシャルネットワーク用のポーカーゲームアプリケーションの開発中に実施されたサーバー（Javaテクノロジ上に構築された）の負荷テストの説明です。
負荷テストの前に、一連のコマンド、ネットワークインターフェイス（Apache MINA）、ゲームエンジン、およびデータベース（Hibernate、MySQL）の基本的なサーバー機能の実装が行われました。 開発プロセスでは、継続的統合（Hudson継続的統合サーバー）、単体テスト（JUnit）、データベース統合テスト、ネットワークインターフェイスとアプリケーションロジックの負荷テストを使用しました。 ゲームのフラッシュクライアントが開発の初期段階にあった状況では、タスクはゲームサーバーの統合と負荷テストを行うことでした。 ポーカーボット向けの命令のアルゴリズムが説明されました。クローンの動作は、ゲームの状況、つまりカードのセットの状態に依存していました。 高度なスキルを持つ自動プレーヤーを作成するという目標がなかったことを考えると、アルゴリズムは実装は簡単でしたが効果的でした。 これにより、自動プレーヤーと実際のプレーヤーを介してゲームサーバーをテストできました。 また、クローンはしばしば、スキルではなく数で人々から勝利を獲得しました。
上記のように、開発中に単体テストが使用されたため、個々のクラスの機能をテストできます。 エンジンの「頭脳」を開発するとき、それなしではありませんでした-ポーカーの「ハンド」を計算します（カードの配布中にカードの勝ちの組み合わせを決定します）。 各組み合わせについて、それらをテストするためのテストが作成されました。 ポーカールールにより、以下の勝ちの組み合わせが決まります。
- ハイカード;
- ペア（同じランクの2枚のカード）;
- 2つのペア（同じランクの2つのペアと同じランクの2つのカード）;
- セット（同じランクの3枚のカード）;
- ストリート（一連の異なるスーツの5枚のカード）;
- フラッシュ（同じスーツの5枚のカード）;
- フルハウス（同じランクの3枚のカードと同じランクの2枚のカード）;
- カレ（同じ宗派の4枚のカード）;
- ストレートフラッシュ（同じスーツの5枚のカードのシーケンス）;
- フラッシュロイヤル（スーツ1枚のハイカード5枚）。
したがって、カードの勝ちの組み合わせは10個あり、単純なケースでは、最大10の計算サイクルで解決策を見つけることができます。 しかし、初心者のポーカープレーヤーでさえ、ゲームの組み合わせの一部に共通の特性があることに気付くでしょう。たとえば、ストレートフラッシュにはストレート（5枚のカードのシーケンス）とフラッシュ（...の同じスーツ）の特性があります。 したがって、計算サイクルの数は4に削減されました。また、各組み合わせに対して一連の単体テストがありましたが、計算の正確性については確実性がありませんでした。 この問題は、ポーカーの組み合わせ（ポーカーの組み合わせが落ちる確率）の統計を使用したテストを作成することで解決しました。
================================================== ===============
| 優勝組み合わせテスト
================================================== ===============
| HIGH_CARD | 17.497％| 34994 |
| ONE_PAIR | 43.847％| 87694 |
| TWO_PAIR | 23.4185％| 46837 |
| セット| 4.8045％| 9609 |
| ストレート| 4.653％| 9306 |
| フラッシュ| 2.989％| 5978 |
| FULL_HOUSE | 2.581％| 5162 |
| クワッド| 0.175％| 350 |
| STRAIGHT_FLUSH | 0.033％| 66 |
| ROYAL_FLUSH | 0.0020％| 4 |
================================================== ===============
handsNumber：200000
このテストでは、200,000のランダムな組み合わせが計算され、その発生数がパーセンテージと数で表示されます（たとえば、セットはテスト9609で〜4.81％のケースで減少しました）。 このテストの結果と統計の不一致は、経験豊富なプレイヤーがよく知っている組み合わせでは、最初にいくつかの特別なルールが考慮されなかったという事実から生じるエラーを示していました。
したがって、開発されたアプリケーションの自動テスト（モジュール、統合、負荷）の有効性が再び確認されました。