Application Auto Testing Efficiency
Attack of the clones.
Episode: Poker.
On one command, without delay, several thousand clones rushed along the narrow network corridors, not knowing the doubts and fear of defeat! In order to meet in a duel and win! Clones, for the most part not masters, but programmed to win, just clearly follow the instructions that, if successful, lead them to the goal. The rules are the same for everyone, each for himself, but there is no chance to survive and defeat a person who is in this mess ...
This is not an episode of the legendary saga "Star Wars" and not a preview of a fantastic story. This is a description of the load testing of the server (built on Java technologies) conducted during the development of the poker game application for social networks.
Load testing was preceded by the implementation of the basic server functionality: a set of commands, a network interface (Apache MINA), a game engine, and a database (Hibernate, MySQL). The development process used continuous integration (Hudson continuous integration server), unit testing (JUnit), database integration testing, load testing of the network interface and application logic. In conditions when the flash client of the game was at the stage of the beginning of development, the task was to conduct integration and load testing of the game server. An algorithm of instructions for poker bots was described, where the behavior of the clone depended on the current state of the game situation, a set of cards. Given that there was no goal to create an automatic player with high skill, the algorithm was simple to implement, but effective. This allowed testing the game server through automatic players along with real players. And clones often took victory from people by number, not skill.
As noted above, unit testing was used during development, which allows testing the functionality of individual classes. It was not without it when developing the “brain” of the engine - calculating the poker “hand” (determining the winning combination of cards during the distribution of cards). For each combination, tests were written to test them. Poker rules determine the following winning combinations:
Thus, there are 10 winning combinations of cards, and in the simple case, a solution can be found for a maximum of 10 calculation cycles. But even a novice poker player will notice that part of the game combinations has common properties, for example, a straight flash has the property of straight (a sequence of five cards ...) and a flash (... of the same suit). Thus, the number of calculation cycles was reduced to 4. And we had a set of unit tests for each combination ..., but there was no certainty about the correctness of the calculation. This problem was solved by writing a test that used statistics on poker combinations (the probability of a poker combination falling out):
=============================== ===================================
| Test of winning combinations
================================================ ==================
| | | HIGH_CARD | 17.497% | 34994 |
| | | ONE_PAIR | 43.847% | 87694 |
| | | TWO_PAIR | 23.4185% | 46837 |
| | | SET | 4.8045% | 9609 |
| | | STRAIGHT | 4.653% | 9306 |
| | | FLUSH | 2.989% | 5978 |
| | | FULL_HOUSE | 2.581% | 5162 |
| | | QUADS | 0.175% | 350 |
| | | STRAIGHT_FLUSH | 0.033% | 66 |
| | | ROYAL_FLUSH | 0.0020% | 4 |
=================================================== ===============
handsNumber: 200000
In this test, 200,000 random combinations are calculated, the number of their occurrence in percentage and in numbers is presented (for example, the set fell in test 9609 in ~ 4.81% of cases). The discrepancy between the results of this test and the statistics indicated an error arising from the fact that initially a number of special rules were not taken into account in combinations that experienced players are well aware of.
Thus, the effectiveness of automatic testing (modular, integration, load) of developed applications was once again confirmed.
Episode: Poker.
On one command, without delay, several thousand clones rushed along the narrow network corridors, not knowing the doubts and fear of defeat! In order to meet in a duel and win! Clones, for the most part not masters, but programmed to win, just clearly follow the instructions that, if successful, lead them to the goal. The rules are the same for everyone, each for himself, but there is no chance to survive and defeat a person who is in this mess ...
This is not an episode of the legendary saga "Star Wars" and not a preview of a fantastic story. This is a description of the load testing of the server (built on Java technologies) conducted during the development of the poker game application for social networks.
Load testing was preceded by the implementation of the basic server functionality: a set of commands, a network interface (Apache MINA), a game engine, and a database (Hibernate, MySQL). The development process used continuous integration (Hudson continuous integration server), unit testing (JUnit), database integration testing, load testing of the network interface and application logic. In conditions when the flash client of the game was at the stage of the beginning of development, the task was to conduct integration and load testing of the game server. An algorithm of instructions for poker bots was described, where the behavior of the clone depended on the current state of the game situation, a set of cards. Given that there was no goal to create an automatic player with high skill, the algorithm was simple to implement, but effective. This allowed testing the game server through automatic players along with real players. And clones often took victory from people by number, not skill.
As noted above, unit testing was used during development, which allows testing the functionality of individual classes. It was not without it when developing the “brain” of the engine - calculating the poker “hand” (determining the winning combination of cards during the distribution of cards). For each combination, tests were written to test them. Poker rules determine the following winning combinations:
- High card;
- A pair (two cards of the same rank);
- Two pairs (two pairs of the same rank and two more cards of the same rank);
- Set (three cards of the same rank);
- Street (a sequence of five cards of different suits);
- Flash (any five cards of the same suit);
- Full house (three cards of the same rank and two cards of the same rank as well);
- Kare (four cards of the same denomination);
- Straight Flash (a sequence of five cards of the same suit);
- Flash royal (five high cards of any one suit).
Thus, there are 10 winning combinations of cards, and in the simple case, a solution can be found for a maximum of 10 calculation cycles. But even a novice poker player will notice that part of the game combinations has common properties, for example, a straight flash has the property of straight (a sequence of five cards ...) and a flash (... of the same suit). Thus, the number of calculation cycles was reduced to 4. And we had a set of unit tests for each combination ..., but there was no certainty about the correctness of the calculation. This problem was solved by writing a test that used statistics on poker combinations (the probability of a poker combination falling out):
=============================== ===================================
| Test of winning combinations
================================================ ==================
| | | HIGH_CARD | 17.497% | 34994 |
| | | ONE_PAIR | 43.847% | 87694 |
| | | TWO_PAIR | 23.4185% | 46837 |
| | | SET | 4.8045% | 9609 |
| | | STRAIGHT | 4.653% | 9306 |
| | | FLUSH | 2.989% | 5978 |
| | | FULL_HOUSE | 2.581% | 5162 |
| | | QUADS | 0.175% | 350 |
| | | STRAIGHT_FLUSH | 0.033% | 66 |
| | | ROYAL_FLUSH | 0.0020% | 4 |
=================================================== ===============
handsNumber: 200000
In this test, 200,000 random combinations are calculated, the number of their occurrence in percentage and in numbers is presented (for example, the set fell in test 9609 in ~ 4.81% of cases). The discrepancy between the results of this test and the statistics indicated an error arising from the fact that initially a number of special rules were not taken into account in combinations that experienced players are well aware of.
Thus, the effectiveness of automatic testing (modular, integration, load) of developed applications was once again confirmed.