Test Plan Template-sayan

Test Plan and Report

com s 417 SPR 2006

Page 1 of 27

Black Box Test Plan for COMS 417 Poker Project

Revision History Version Date Author 0.1 09/05/05 SM 0.2 01/20/06 JD

Change Initial Document Altered for COMS 417

GROUP NUMBER 02 April Shinatrakool XX% EFFORT Sayan Ranu XX% EFFORT Amish M Gangar XX% EFFORT

Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 2 of 27

1 Test Design 1.1 TASK 1: TESTING THE PLAYER CLASS // What are the overall testing goals? What is the testing strategy? (1-2 paragraphs) Ans: The overall testing goal is to make sure that the player class is doing all the tasks properly that a player sitting at the table is supposed to do. The player class represents an individual player and keeps track of their hand and the amount of money they have. Thus the primary goals are:  To make sure that the transaction of money is taking place properly.  The details of a player are stored and retrieved correctly. This includes transaction involving only bank and transaction between the bank and a pot.  Cards dealt to a player are dealt properly and in a randomized fashion. The testing strategy is based on the particular method being tested. First, we have created six players and then used them to test the methods. The players have been first setup with varied values. getName() : check if the name returned is same as what expected. getBank() : check if amount returned is same as what expected. We have used equivalence classes to test all possible types. addToBank(): check if money is added properly to the bank. We have used equivalence classes to test all possible types. subtractFromBank(): check if money is subtracted from the bank properly. We have used equivalence classes to test all possible types. getMoneyInPot(): check if money is added to the pot properly. We have used equivalence classes and random value testing. setHand(): check if card is dealt properly:. We have used random value testing. // What is the overall plan for testing? (1 paragraph) Ans: The overall testing plan is to simulate all possible conditions that a player class will face during an actual operation of the Poker game. Since the methods in the class won’t be used in the same way, the strategies to test them were based on the ways they will be used while in actual operation. The methods were thus tested with values that it would normally expect and also with values that it won’t expect to make sure that it doesn’t fail and reacts in a stable manner. // What are the units to be tested? (1 paragraph) Give the name of the units (packages) being tested and why these units are being tested.

Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 3 of 27

Ans: We have tested the Player class in the DataObjects package. The player class represents an individual player and keeps track of their hand and the amount of money they have. // What is the overall testing setup? (1 paragraph) - Who will be doing what tests? Sayan Ranu - Where will the tests be done? Atanasoff 116A computer lab - What is the testing environment? Computer Lab with Eclipse installed. We used Junit to test the classes. 1.2

TASK2

1.2.1 OVERALL IDEA // here you describe your idea of how you will test this requirement. // Be sure to include a discussion in what kind of testing strategy was used to test here (equivalent-class partitioning, random, boundary testing, etc.) // In other words, how will you be confident that this requirement is being met? The overall testing goal for this task is to test the TexasHoldEm class to see whether it is working properly or not. The testing strategies that we use for black box testing are negative value, boundary testing, equivalence class testing, Black Box testing and random testing by developing JUnit test cases. Some of the testing which were not able to be tested by JUnit, have been manually tested and documented appropriately.

// What is the overall plan for testing? (1 paragraph) Firstly, the testing has been performed on the most important methods of the TexasHoldEm class. These methods play a very crucial role in proper functioning of the game. public void bet() Handles all the betting of the players and is called before the flop, after the flop, after the turn, and after the river. void fold(String cPlayer) Removes the players from the eligibility vectors of the pots currentPlayer, the current player's seat at the table void raise(String cPlayer, long raiseAmount) Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 4 of 27

Function used for players to raise their bets, will create new pots if the raise goes over the pot limit, which is determined upon the creation of the pot currentPlayer, the players seat at the table raiseAmount the amount the player would like to raise after calling. void call(String cPlayer) Calls the raise function. Some of the other methods tested in this class include the following : public void pay() This method determines the winner(s) of each pot and pays them accordingly. void payMoneyOwed(String cPlayer) A function that will take the amount of money needed from the player to continue play and add it to the pot. currentPlayer and index where the player is sitting at the table public void giveAllMoneyBack() Gives back the money from the pot to the players.

// What are the units to be tested? (1 paragraph) Give the name of the units (packages) being tested and why these units are being tested. The unit that being tested is from server package, TexasHoldEm.java because this class performs different functionalities of the poker game such as pay, raise, fold etc. // What is the overall testing setup? (1 paragraph) - Who will be doing what tests? Amish M Gangar - Where will the tests be done? Atanasoff 116A computer lab - What is the testing environment? Computer Lab 1.3 TASK3 … similar to Task 1 1.4 TASK4 What are the overall testing goals? What is the testing strategy? (1-2 paragraphs) Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 5 of 27

Ans: The overall testing goal is to find the reason behind the bug because while sending a private message, sometimes it is displayed with three junk characters on the chat window of the person the message was sent to. We have used black box testing. We created three equivalent classes and used each one of them to test the method. //What is the overall plan for testing? (1 paragraph) Ans: The overall testing plan is to generate all possible types (equivalence classes) and check how the method handles each one of them. // What are the units to be tested? (1 paragraph) Give the name of the units (packages) being tested and why these units are being tested. Ans: We have tested the CasinoFloor class in the ClientGUI package. This package contains all the GUI classes that the client interacts with. The class initializes and provides all the function of the Casino Floor tab. // What is the overall testing setup? (1 paragraph) - Who will be doing what tests? Sayan Ranu - Where will the tests be done? Atanasoff 116A computer lab - What is the testing environment? Computer Lab with Eclipse installed. We used Junit to test the classes.

2 Details of Tests 2.1

TASK ONE

2.1.1 OVERALL IDEA // here you describe your idea of how you will test this requirement. // Be sure to include a discussion in what kind of testing strategy was used to test here (equivalent-class partitioning, random, boundary testing, etc.) // In other words, how will you be confident that this requirement is being met? The testing strategy is based on the particular method being tested. First, we have created six players and then used them to test the methods. The players have been first setup with varied values. getName() : We have tested this method to see if the name returned is same as what is expected. This method is fairly simple to test. We first set up a player with a particular Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 6 of 27

name and amount, and then this method is called to check if the name returned is the name it was set up with. We have used equivalent-class partitioning to test this method. There were two equivalent classes, one containing normal letters like in a normal name, and the other containing numbers. We are confident that there is no bug in this method since we have tested all the possible equivalence classes. getBank() : We have tested this method to see if the bank amount returned is same as what is expected. This method is fairly simple to test. We first set up a player with a particular name and amount, and then this method is called to check if the value returned is the amount it was set up with. We have used equivalent-class partitioning, and boundary value testing to test this method. There were three equivalent classes: positive values, negative, values, and 0. We are confident that there is no bug in this method since we have tested all the possible equivalence classes, and the boundaries. addToBank(): We have tested this method to see if the money is added properly to the bank of a particular player. We first set up a player with a particular name and amount, and then this method is called with a particular amount to check if the value returned is what is expected. We have used equivalent-class partitioning, and boundary value testing to test this method. There were three equivalent classes: positive values, negative, values, and 0. We are confident that there is no bug in this method since we have tested all the possible equivalence classes, and the boundaries. subtractFromBank(): We have tested this method to see if money is subtracted properly to the bank of a particular player. We first set up a player with a particular name and amount, and then this method is called with a particular amount to check if the value returned is what is expected. We have used equivalent-class partitioning based on the amount we are subtracting and the resulting amount in the bank, and boundary value testing to test this method. There were three equivalent classes: positive values, negative, values, and 0. One problem we faced initially is to check the other part of this method which deals with adding the subtracted money properly to the pot assigned. Since the getMoneyInPot() method has not been tested yet, we decided to concentrate only on the subtraction part. We are confident that the subtraction part has been tested thoroughly since we have tested all the possible equivalence classes, and the boundaries. We have tested the addition part in the testcase of getMoneyInPot(). getMoneyInPot():We have tested this method to see if money is added properly to the pot of a particular player when the subtractFromBank() method is called. We first set up a player with a particular name and amount, and then the the subtractFromBank() method is called with a particular amount to check if the value returned is what is expected. We have used equivalent-class partitioning, random value testing, and boundary value testing to test this method. There were two equivalent classes: positive values, and negative values. Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 7 of 27

For the random value testing with positive amount, we created the operation profile in such a way that 75% of the time the money added to the pot is less than money available, and the rest of the time the money is more than the available in the bank. For the random value testing with negative amount, we created the operation profile with values between 0 and -10000. We didn’t have any statistics available to find out the amount which people normally bet during an actual game, so we came up with reasonable amounts to test the method. We are confident that this method has been tested thoroughly since we have tested all the possible equivalence classes, and the boundaries. setHand():We have tested this method to see if card is dealt properly during a game. We has first created a new deck and then shuffled it. Then we have dealt to cards from the deck to five players. We have used random value testing by repeating this process 10000 times and dealing cards to players. Each time the dealing process is completed we have checked that:  no player has got a card already dealt to some player.  A card dealt is no more in the deck.  We are confident that there is no bug in this method since we have simulated dealing cards in actual operation 10000 times. This is in a way random value testing since the shuffling of cards and then dealing it is done in a random fashion.

2.1.2

LIST OF TEST CASES

Group

TestCase Description getName() The input tests the equivalence class of strings with letters The input tests the equivalence class of strings with numbers getBank() The input tests the equivalence class of positive amounts. Simanta Mitra

Inputs

Expected Outputs “april”

Actual Outputs “april”

Comment s correct

testPlayer5 =new Player("1234", 2100100000);

“1234”

“1234”

correct

testPlayer1 =new Player("sayan", 1000);

1000

1000

Correct

testPlayer2= new Player("april",1000);

[email protected]

4-3463

com s 417 SPR 2006

addToBan k()

Test Plan and Report

Page 8 of 27

The input tests the equivalence class of positive 0.

testPlayer3 0 =new Player("amish", 0);

0

Correct

The input tests the positive boundary values.

testPlayer5 =new Player("1234", 2100100000);

2100100000

2100100000

correct

The input tests the equivalence class of negative amounts.

testPlayer2= new Player("april",1000);

-1000

-1000

Correct

The input tests the negative boundary values.

testPlayer6 =new Player("1235", -2100100000);

-2100100000

-2100100000

Correct

The input tests the equivalent class of adding 0 to the bank amount

Amount in 1000 Bank: 1000 Amount added: 0

1000

Correct

The input tests the equivalent class of adding negative amount. This also tests the equivalence of a negative resulting amount

Amount in -1001 Bank: -1000 Amount added: -1

-1001

Correct

Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

subtractFr omBank()

Test Plan and Report

Page 9 of 27

The input tests the equivalent class where the resulting amount is 0 The input tests the equivalent class of adding a positive amount The input tests the boundary value.

Amount in 0 Bank: 0 Amount added: 0

0

Correct

Amount Bank: 0 Amount added:100

100

Correct

Amount in 2100100000 Bank: 100000 Amount added: 2100000000

2100100000

Correct

The input tests the equivalent class of subtracting 0 from the bank amount The input tests the equivalent class of subtracting a positive amount from the bank amount The input tests the equivalent class of subtracting an amount which is more than the amount in the bank. The input tests the

Amount in 1000 Bank: 1000 Amount subtracted: 0

1000

Correct

Amount in 95400 Bank: 100000 Amount subtracted: 4600

95400

Correct

Amount in 1000 Bank: 1000 Amount subtracted: 2001000

1000

Correct

Amount Bank:

100000

Correct

Simanta Mitra

in 100

in 100000

[email protected]

4-3463

com s 417 SPR 2006 boundary value

Test Plan and Report

Page 10 of 27

2100100000 Amount subtracted: 2100000000

getMoney InPot()

The input tests the equivalent class of subtracting a negative amount from the bank amount

Amount in 0 Bank: 0 Amount subtracted: -1

Random Value Testing. The test starts with a player having 100000 in his bank. The random amounts between 0 and 125000 are subtracted from his bank

Amount in Bank starts with: 100000 Amount subtracted: 0 to 125000

Simanta Mitra

If amount subtracted is less than or equal to amount in bank then the money in the Amount put in pot should be pot depends on the initial the amount amount in pot subtracted. + amount subtracted from bank. Else amount in pot should be the [email protected]

-1

BUG! Subtractin g a negative value from the bank transfers money from the pot to the bank, which should not happen. It should block transactio ns trying to subtract negative amounts. When amount Correct subtracted from bank less or equal to amount in bank: initial amount in pot + amount subtracted from bank. When amount subtracted from bank more that amount in 4-3463

com s 417 SPR 2006

Test Plan and Report

amount. The getMoneyIn Pot() method is then called to check if the money transaction is taking as expected or not. This tests the equivalence classes of positive numbers smaller and larger than the amount in the bank. The test has been carried out 100000 times. This tests the Should block equivalence the transaction classes of subtracting negative numbers from the amount in bank. This test has been carried out 10 times.

Simanta Mitra

Page 11 of 27

amount it had bank: Initial before the amount in pot. transaction took place.

Initial amount Pot.

[email protected]

Negative in amount

BUG! Subtractin g a negative value from the bank transfers money from the pot to the bank, which should not happen. It should block transactio ns trying to subtract negative 4-3463

com s 417 SPR 2006

Test Plan and Report

Page 12 of 27 amounts

2.1.3 TEST PROCEDURES // here describe the setup, the steps for testing etc. // REPEAT The tests were done using Junit in Eclipse. There was a setup() method which initialized 6 testplayers. The testplayers were initialized with varied name and amount, thus covering the equivalent classes of the argument name and bank amount. After the players were setup, the individual test methods used these players to test the methods. getName():We first set up players with a particular name and amount, and then this method is called to check if the name returned is the name it was set up with. We used assertEquals to match the expected and actual outputs. getBank():We first set up players with a particular name and amount, and then this method is called to check if the value returned is the amount it was set up with. We used assertEquals to match the expected and actual outputs. addToBank():We first set up players with a particular name and amount, and then this method is called on players with a particular amount to check if the value returned is what is expected. We used assertEquals to match the expected and actual outputs. The getBank() method was used to get the amount in the bank of a particular player. This getBank() method gives us the actual output. subtractFromBank():We first set up players with a particular name and amount, and then this method is called on players with a particular amount to check if the value returned is what is expected. We used assertEquals to match the expected and actual outputs. The getBank() method was used to get the amount in the bank of a particular player. This getBank() method gives us the actual output. getMoneyInPot():We first set up players with a particular name and amount. Then the subtractFromBank() method is called on players with a particular amount. The we compare the expected output and the actual output returned by getMoneyInPot() using assertEquals. Since the strategy employed to test this method is random value testing the process after setting up a player has been repeated 10000 times. setHand():We first set up players with a particular name and amount. Then we create a new deck and shuffle it. After this we create player hands for each of the players on which this method was tested. The player hands are created by removing cards from the shuffled deck. Once the player hands are created, we call the setHand() method with the player hands as input. This completes the first step of setting up the players to test the Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 13 of 27

method. After this we call the getHand() method to get the cards assigned to the players and do the rest of the testing as described in section 2.1.1. The whole process of setting up and testing has been repeated 10000 times. 2.2

TASK TWO

The testing strategy is based on the particular method being tested. First, we have created six players and then used them to test the methods. The players have been first setup with varied values. void bet(): We tested this method to see if it handles the player betting during the game play. Since this method does not take any arguments nor does it return anything it was fairly easy to test. We tested this method by calling it during the game play but it does not seem to affect the game in any way. We are confident about our tests and the test results since the only way to use this method is during the game play. void raise(String cPlayer, long raiseAmount): We tested this method to see if it raises the cPlayer with the raiseAmount provided. This method works fine when we tested it with positive numbers which were less than the amount the respective player had in his/her bank. When we tested the function for negative numbers it accepted them instead of rejecting. The function also did not show the extra pot where the money (owed money) was put into after taking it from the players bank. We aer confident about our tests and the test results since we have done all possible boundary value and equivalence class testing on this method. void fold(cPlayer):We tested this method to see if it folds the player from the game. During our tests we found that the method was unable to fold the player and allowed the player to continue to play. We are confident about our tests and the test results since there is only one way to test this method. void call(): We tested this method to see if it allows the players to call during the game play. Since this fuction performs the same tasks as raise method we are confident that the tests which we used for the raise function can be applied to this method as well. The test results for this method is same as raise method. void pay(): We tested this method to see if it determines the winner of each pot and pays them accordingly. On our tests we found that this function is unable to determine the winner and so also unable to pay the player any money which they have won. This player simply adds one to the number of handswon for each player. We are confident about our tests on this function since this function does not take any arguments and the only way to test this is call it during the game play.

Simanta Mitra

[email protected]

4-3463

Test Plan and Report

com s 417 SPR 2006

Page 14 of 27

void payMoneyOwed():We tested this method to see if it pays the money from the bank of the players who are currently owing money to other players playing the game. This method worked correctly during our tests when the player who owes the money has enough money in his/her bank to pay the other players. On the other hand, when the player does not have enough money to pay the money he owes the method continues to let that player continue without showing any error or paying the money he owes. We are confident about our tests and the test results since we have checked this method for all possible boundary value and equivalence class testing. void giveAllMoneyBack():We tested this method to see if it takes the money from the pot and put it in players bank. This method worked incorrectly during our tests, in that it added the money to the players bank but did not reduce it from the pot. We are confident about our test and the test results since the function does not take any arguments nor does it returns any. Thus there is only one way to test this function.

2.2.1

LIST OF TEST CASES

Group

void bet()

TestCase Description Initial Bank Amount Inside domain

void raise(String Inside cPlayer, long domain raiseAmount)

Simanta Mitra

Inputs -1000 20

Outside Domain

200

Negative Value

-200

Expected Outputs Some error

Actual Outputs No error

Comment s

Handle player betting. Add 20 from the current player to the current pot. Only the amount left in the bank should be added to the pot. Should not allow the money to be added to the pot.

No output.

Incorrect.

[email protected]

Adds 20 from Correct. the current player to the current pot. Throws exception

Incorrect

-200 added to Incorrect. the pot and the player bank money remains the 4-3463

com s 417 SPR 2006

Test Plan and Report

void fold()

Inside Domain

Player name

void call()

Inside Domain

-

void pay()

Inside domain

-

void payMoneyOwed()

Inside Domain

-

Outside Domain.

-

void Inside giveAllMoneyBack() Domain

-

Simanta Mitra

Page 15 of 27

same. Fold (End Does not fold Incorrect. the game of the player. The the ) player. folded player is still able to add the money into the pot. Raise the Raises the Correct. current current player player will will 0 as the 0 as the high blind. high blind. Determines Unable to Incorrect the winner determine the and pay(s) winner. Just them adds 1 to accordingly. handswon . Pay the Pays the Correct money money owed owed to the to the other other players players playing the playing the game. game. Throw Does not Incorrect Exception throw exception, player continues to play the game even if he/she does not have the money he/she owes other players playing the game. Transfer Adds money Incorrect money from to the bank the pot to but does not the players reduce the bank. money from the pot.

[email protected]

4-3463

com s 417 SPR 2006 void reset()

Test Plan and Report Inside Domain

-

- Extra Credit. int whereIs(String Inside playerName) Domain

player Name

Set the players, dealer, cards, pots to null. Return the position of playerName

Page 16 of 27 Does not set Incorrect. the dealer to null. Player, cards, pots set to null. Returns the Correct position of playerName

- Extra Credit 2.2.2 TEST PROCEDURES // here describe the setup, the steps for testing etc. // REPEAT The tests were done using Junit in Eclipse. There was a setup() method which initialized 4 testplayers. The testplayers were initialized with varied name and amount, thus covering the equivalent classes of the argument name and bank amount. After the players were setup, the individual test methods used these players to test the methods. void bet():We first set up players with a particular name and amount, and then this method is called to check if the method allowed the players to bet in the game. We used printPlayerStats() method to compare the expected and the actual outputs. void raise(String cPlayer, long raiseAmount): We first set up players with a particular name and amount, and then this method is called to check if the method raised the current player with the raiseAmount provided. We used printPlayerStats() method to compare the expected and the actual outputs.

void fold(cPlayer): We first set up players with a particular name and amount, and then this method is called to check if the method folds the current player out of the game. We used printPlayerStats() method to compare the expected and the actual outputs. void call():We first set up players with a particular name and amount, and then this method is called to check if the method allows the current player to call during the game. We used printPlayerStats() method to compare the expected and the actual outputs. void pay():We first set up players with a particular name and amount, and then this method is called to check if the method is able to determine the winner and pay him the Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 17 of 27

amount he/she has won. We used printPlayerStats() method to compare the expected and the actual outputs. void payMoneyOwed(): We first set up players with a particular name and amount, and then this method is called to check if the method is able to pay back the money which is owed by the players playing the game. We used printPlayerStats() method to compare the expected and the actual outputs. void giveAllMoneyBack():We first set up players with a particular name and amount, and then this method is called to check if it is able to pay back all the money to the players from the pot. We used printPlayerStats() method to compare the expected and the actual outputs. 2.3 2.3.1

TASK THREE OVERALL IDEA

// here you describe your idea of how you will test this requirement. // Be sure to include a discussion in what kind of testing strategy was used to test here (equivalent-class partitioning, random, boundary testing, etc.) // In other words, how will you be confident that this requirement is being met? The testing is based on the particular method being tested. So, we came up with many SevenCardHand objects with various cards value to use for testing. void determineValue() We have tested this method to see if it give the correct hand’s score or not. We first set up the SevenCardHand object by specified what are the seven cards. Then we call this method to determine the value of this hand. However, since it is a void function, we cannot see the result directly. Therefore, we have to call printValue() method to get the result. We have used equivalent-class partitioning and boundary testing to test this method which are Inside Domain – this test with the inputs from 8 – 59 for a deck of cards (52 cards). Below Boundary – this test with the inputs below 8. Above Boundary – this test with the inputs above 59. We are confident that there is no bug in this method since we have tested all the possible equivalence classes and boundary. boolean isBetterThan(SevenCardHand other) We have tested this method to see if the comparision of the two hands’ score to each other is correct or not. We have used equivalent-class partitioning to test this method. First we have create a base SevenCardHand object which we use it to compare with many of other SevenCardHand objects. These other hands will consist of the same community cards (first five cards) to simulate the real poker game situation.

Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 18 of 27

The methods compared ok if the two hands has different values which came from determineValue(). However, we found a bug when both hands has the same value. For example, thisHand has a pair of 10: 10H,10D and the otherHand also has a pair of 10: 10H,10S. We can see that both hands consist of the same 10 because this is one of the community cards. If we do thisHand.isBetterThan(otherHand) thisHand, it will returns false which is correct. However, if we switch this around to otherHand.isBetterThan(thisHand), it returns false which is wrong. Then I select the next four important methods to test which are Vector> sortByValue(Vector oldVec) We have tested this method to see if it sorts the seven cards’ value from the highest to the lowest, i.e. Ace down to two, or not. We have used equivalent-class partitioning and boundary testing to test this method which are Inside Domain – this test with the inputs from 8 – 59 for a deck of cards (52 cards). Below Boundary – this test with the inputs below 8. Above Boundary – this test with the inputs above 59. We are confident that there is no bug in this method since we have tested all the possible equivalence classes and boundary. Vector> sortBySuit(Vector oldVec) We have tested this method to see if it sorts the seven cards’ suit from diamond, spade, heart and club. Also, we have tested to see if the cards’ value are sorted in each suit category from the highest to the lowest, i.e. Ace down to two, or not. We have used equivalent-class partitioning and boundary testing to test this method which are Inside Domain – this test with the inputs from 8 – 59 for a deck of cards (52 cards). Below Boundary – this test with the inputs below 8. Above Boundary – this test with the inputs above 59. We are confident that there is no bug in this method since we have tested all the possible equivalence classes and boundary. boolean isEqualTo(SevenCardHand other) We have tested this method to see if the comparision of the two hands’ score to each other is correct or not. The methods compared ok. However, We have used equivalent-class partitioning to test this method which are Same Hand – this compare the exactly same seven cards. One card is different suit. One card is different number. The otherHand doesn’t have seven cards. The method is ok unless the 3.4 because it did not give error. We believe that it should not be able to compare at the first place. Vector<String> getPlayersCards() We have tested this method to see if it returns the two player’s cards correctly or not. Simanta Mitra

[email protected]

4-3463

Test Plan and Report

com s 417 SPR 2006

Page 19 of 27

Inside Domain – this test with the inputs from 8 – 59 for a deck of cards (52 cards). Below Boundary – this test with the inputs below 8. Above Boundary – this test with the inputs above 59. We found a bug when we tested the inside domain. For example, we have set the SevenCardHand object = (20,25,37,11,42,40,46) which the player’s cards are the last two cards. It gave a wrong result for 46 in particular since it prints jack_clubs instead of jack_hearts. 2.3.2

LIST OF TEST CASES

Group

TestCase Inputs Description determineValue() Inside (8,9,10,11,25,51,46) -> (*Use domain (2D,2S,2H,2C,6S,12C,11H) printValue()) (between 8 and 52) (20,25,37,11,42,40,13)-> (5D,6S,9S,2C,10H,10D,3S) (10, 8, 37, 11, 42, 40, 13) ->(2H,2D, 9S,2C,10H,10D,3S) Below (2,3,4,5,6,40,20) boundary (below 8)

IsBetterThan()

Above boundary (above 59)

(61, 60, 59, 11, 42, 40, 13)

Base hand(this hand) a pair of 9's vs. a pair of 10's three 5's vs. pair of 10's a pair of 10's vs. a pair of 10's

(20,25,37,11,42,40,13) -> (5D,6S,9S,2C,10H,10D,3S)

Expected Outputs four 2’s

Actual Outputs

Comments

four 2’s

Correct

a pair of 10's

a pair of 10's

Correct

a full house with 2's over 10's Throw exception

a full house with 2's over 10's a full house with 1's over 0's

Correct

Throw exception

(20,25,37,11,42,38,14) -> (5D,6S,9S,2C,10H,9H,3H)

true

true

Correct

(20,25,37,11,42,21,22) -> (5D,6S,9S,2C,10H,5S,5H) (20,25,37,11,42,41,48) -> (5D,6S,9S,2C,10H,10S,12D)

false

false

Correct

false

false

Correct

false

Wrong since this hand has a 10S, it is

If switch this hand and other true hand then compare

Simanta Mitra

Probably this will not going to happen. a pair of 15's Probably and another this will pair of 10's not going to happen.

[email protected]

4-3463

com s 417 SPR 2006

sortByValue()

Test Plan and Report

isEqualTo()

getPlayerCards()

better than the other hand. Correct

Same with (20,25,37,11,42,40,13) -> base hand (5D,6S,9S,2C,10H,10D,3S)

false

false

Inside domain

(46,42,40, 37,25,20,11) (58,56,46,40, 25,20,15) (56,55,46,20, 13,-5,-7) (100,99,56, 44,32,13,8)

(46,42,40, 37,25,20,11) (58,56,46,40, 25,20,15) (56,55,46,20, 13,-5,-7) (100,99,56, 44,32,13,8)

(56,40,20,25, 58,46,40) (56,20,17,13, 5,46,55) (100,56,44,32, 8,13,99)

(56,40,20,25, 58,46,40) (56,20,17,13, 5,46,55) (100,56,44,32, 8,13,99)

(20,25,37,11,42,40,46) -> (5D,6S,9S,2C,10H,10D,11H) (20,25,37,11,42,40,49) -> (5D,6S,9S,2C,10H,10D,12S) (20,25,37,11,42,41,46) -> (5D,6S,9S,2C,10H,10S,11H)

true

true

Correct

true

true

Correct

true

true

Correct

(20,25,37,11,42,41) -> (5D,6S,9S,2C,10H,10S)

Throw exception

true

Wrong. It shouldn’t be able to compare since it has fewer cards.

(20,25,37,11,42,40,46) (20,56,25,58,15,46,40)

sortBySuit()

Page 20 of 27

Correct Correct

Below boundary Above boundary

(20,-5,-17,56,13,55,46) ->(-5, -17 are below) (13,99,8,56,44,32,789)

Inside domain Below boundary Above boundary

(20,25,58,56,15,40,46) -> (5D,6S,AH,AD,3C,10D,11H) (20,5,17,56,13,55,46) -> (5D,1S,4S,AD,3S,KC,JH) (13,99,8,56,44,32,789) -> (3S, C, 2D,AD, JD, 8D, D)

Base hand(this hand) Same with base hand 1ast card is different a pair of 10 but different suit Not enough cards

(20,25,37,11,42,40,46) -> (5D,6S,9S,2C,10H,10D,11H)

Inside domain

(20,25,37,11,42,40,46) -> (10D, 11H) (10D, 11H) (5D,6S,9S,2C,10D,11H) (20,25,37,11,42,40,46) -> (ten_diamonds, (ten_diamonds, Wrong. (5D,6S,9S,2C,10D,11H) jack_hearts) jack_clubs) [email protected] 4-3463

Simanta Mitra

Correct Correct (set card # that > 100 to 100) Correct Correct Correct (set card # that > 100 to 100)

com s 417 SPR 2006 Below boundary Above boundary

2.3.3

Test Plan and Report (20,25,37,11,42,5 ,49) -> (5D,6S,9S,2C,10H,_,12S) (20,25,37,11,42,66 ,49) -> (5D,6S,9S,2C,10H,_,12S)

(empty, queen_spades) Throw exception

Page 21 of 27 (empty, queen_spades) error

TEST PROCEDURES

// here describe the setup, the steps for testing etc. The tests were developed using JUnit in Eclipse which performed on a desktop computer that running Windows XP. We have initialized many SevenCardHand objects with various cards value to use for testing. void determineValue() We first set up the SevenCardHand object by specified what are the seven cards. Then we call this method to determine the value of this hand. However, since it is a void function, we cannot see the result directly. Therefore, we have to call printValue() method to get the result. Then we use assertEquals() to compare the expected and actual outputs. boolean isBetterThan(SevenCardHand other) First, we have created a base SevenCardHand object which we use it to compare with many of other SevenCardHand objects. These other hands will consist of the same community cards (first five cards) to simulate the real poker game situation. Then call this method and use assertEquals() to compare the expected and actual outputs. Vector> sortByValue(Vector oldVec) We have created a SevenCardHand object and call this method to sort the seven cards’ value from the highest to the lowest, i.e. Ace down to two. Then we use assertEquals() to compare the expected and actual outputs. Vector> sortBySuit(Vector oldVec) We have created a SevenCardHand object and call this method to sorts the seven cards’ suit from diamond, spade, heart and club and also sort the seven cards’ value from the highest to the lowest, i.e. Ace down to two. Then we use assertEquals() to compare the expected and actual outputs. boolean isEqualTo(SevenCardHand other) First, we have created a base SevenCardHand object which we use it to compare with many of other SevenCardHand objects. These other hands will consist of the same community cards (first five cards) to simulate the real poker game situation. Then call this method and use assertEquals() to compare the expected and actual outputs. Vector<String> getPlayersCards() We have created a base SevenCardHand object and call this method to get the player’s cards. Then we use assertEquals() to compare the expected and actual outputs. Simanta Mitra

[email protected]

4-3463

Correct Probably this will not going to happen.

com s 417 SPR 2006

2.4

Test Plan and Report

Page 22 of 27

TASK FOUR

2.4.1 OVERALL IDEA // here you describe your idea of how you will test this requirement. // Be sure to include a discussion in what kind of testing strategy was used to test here (equivalent-class partitioning, random, boundary testing, etc.) // In other words, how will you be confident that this requirement is being met? We have used black box testing. We created three equivalent classes and used each one of them to test the method. The overall testing plan is to generate all possible types (equivalence classes) and check how the method handles each one of them. Since we already know that there is a bug, because it prints three junk characters at time, we need to find the equivalence class, which the program can’t handle properly. So the majority of the testing involves generating all the possible equivalence classes and make sure that we don’t leave out any. We are convenient about the requirement being met since we have covered all the possible equivalence classes that the application will have to deal with during actual operation. 2.4.2

LIST OF TEST CASES

Group putMessa ge()

TestCase Description The input tests the equivalence class of strings with letters The input tests the equivalence class of strings with numbers The input tests the equivalence class string with numbers and

Simanta Mitra

Inputs “how r u”

Expected Outputs “how r u”

Actual Outputs “how r u”

Comment s correct

“1234”

“1234”

“1234”

correct

“I am 2 tired”

“I am 2 tired” “I am 2 tired”

[email protected]

Correct

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 23 of 27

letters The input “how r u\n” tests the equivalence class strings with endline characters

“how r u\n”

The input “how r u\t” tests the equivalence class strings with tabs characters

“how r u\t”

“how r u” BUG! with junk Whenever characters there is an endline character at the end of the message it prints t he junk characters “how r u\t” correct

2.4.3 TEST PROCEDURES // here describe the setup, the steps for testing etc. // REPEAT The tests were done using Junit in Eclipse. First we had to set up the server and client so that it’s possible to exchange private messages between the users. To do that, first we ran the server, then two clients. Each of the clients (players) then registered with a username and password. Once the two players are logged in, we test each of our equivalence classes by making one of the players send a message to the other player. The output was checked in the chat window of the other player. We could not automate this testing process since it involves GUI, which can be tested only when it’s running in actual operaiton.

2.5

EXTRA CREDIT

2.5.1 SEVENCARDHAND 2.5.1.1 overall idea

The overall testing goal for this task is to test the some more methods from SevenCardHand class to see whether it is working properly or not. Those methods were used to test for task three. The testing strategies that we use for black box testing are negative value, boundary testing by developing JUnit test cases. Simanta Mitra

[email protected]

4-3463

Test Plan and Report

com s 417 SPR 2006

Page 24 of 27

First, we came up with many SevenCardHand objects with various card’s value to use for testing. String printValue() We have tested this method to see if it give the correct hand’s score or not. Also, this method is used to test with the determineValue(). We first set up the SevenCardHand object by specified what are the seven cards. Then we call determineValue() to determine the value of this hand. Then, we can call this method to get the result. We have used equivalent-class partitioning and boundary testing to test this method which are Inside Domain – this test with the inputs from 8 – 59 for a deck of cards (52 cards). Below Boundary – this test with the inputs below 8. Above Boundary – this test with the inputs above 59. We are confident that there is no bug in this method since we have tested all the possible equivalence classes and boundary. void printCards() We have tested this method to see if it print the player’s cards correctly or not. We have used equivalent-class partitioning and boundary testing to test this method which are Inside Domain – this test with the inputs from 8 – 59 for a deck of cards (52 cards). Below Boundary – this test with the inputs below 8. Above Boundary – this test with the inputs above 59. We are confident that there is no bug in this method since we have tested all the possible equivalence classes and boundary. void printCC() We have tested this method to see if it print the community cards correctly or not. We have used equivalent-class partitioning and boundary testing to test this method which are Inside Domain – this test with the inputs from 8 – 59 for a deck of cards (52 cards). Below Boundary – this test with the inputs below 8. Above Boundary – this test with the inputs above 59. We are confident that there is no bug in this method since we have tested all the possible equivalence classes and boundary. However, this method prints six cards which include one of the player’s cards while it should only prints five cards. 2.5.1.2 list of test cases

Group

TestCase Description printValue() Inside domain Simanta Mitra

Inputs (8,9,10,11,25,51,46) -> (2D,2S,2H,2C,6S,12C,11H [email protected]

Expected Outputs four 2’s

Actual Outputs four 2’s

Comments Correct 4-3463

com s 417 SPR 2006

Test Plan and Report

(between 8 ) and 52) (20,25,37,11,42,40,13)-> (5D,6S,9S,2C,10H,10D,3S) (10, 8, 37, 11, 42, 40, 13) ->(2H,2D, 9S,2C,10H,10D,3S) Below (2,3,4,5,6,40,20) boundary (below 8)

a pair of 10's

a pair of 10's

Correct

a full house with 2's over 10's Throw exception

a full house with 2's over 10's a full house with 1's over 0's

Correct

Throw exception

a pair of 15's and another pair of 10's

Inside (8,9,10,11,25,51,46) -> domain (2D,2S,2H,2C,6S,12C,11H (between 8 ) and 52)

2 of Diamonds,2 of Spades,2 of Hearts,2 of Clubs,6 of Spades

2 of Diamonds,2 of Spades,2 of Hearts,2 of Clubs,6 of Spades,Queen of Clubs,

(20,25,37,11,42,40,13)-> (5D,6S,9S,2C,10H,10D,3S)

5 of Diamonds,6 of Spades,9 of Spades,2 of Clubs,10 of Hearts

5 of Diamonds,6 of Spades,9 of Spades,2 of Clubs,10 of Hearts,10 of Diamonds, 2 of Hearts,2 of Diamonds,9 of Spades,2 of Clubs,10 of Hearts,10 of Diamonds, 0 of Hearts,0 of Clubs,1 of Diamonds,1 of Spades,1 of Hearts,10 of Diamonds,

Above boundary (above 59) printCC

Page 25 of 27

(61, 60, 59, 11, 42, 40, 13)

(10, 8, 37, 11, 42, 40, 13) 2 of Hearts,2 ->(2H,2D, of Diamonds,9 9S,2C,10H,10D,3S) of Spades,2 of Clubs,10 of Hearts Below boundary (below 8)

(2,3,4,5,6,40,20)

Above boundary (above 59)

(61, 60, 59, 11, 42, 40, 13)

Simanta Mitra

[email protected]

0 of Hearts,0 of Clubs,1 of Diamonds,1 of Spades,1 of Hearts

Probably this will not going to happen. Probably this will not going to happen. Correct but print extra

Correct but print extra

Correct but print extra

Correct but print extra and probably this will not going to happen. of Spades, of of Spades, of Correct but Diamonds,Ace Diamonds,Ace print extra of Clubs,2 of of Clubs,2 of and 4-3463

Test Plan and Report

com s 417 SPR 2006

printCards()

Inside (8,9,10,11,25,51,46) -> domain (2D,2S,2H,2C,6S,12C,11H (between 8 ) and 52) (20,25,37,11,42,40,13)-> (5D,6S,9S,2C,10H,10D,3S)

Below boundary (below 8) Above boundary (above 59)

Clubs,10 of Clubs,10 of probably Hearts,10 of Hearts,10 of this will Diamonds, Diamonds, not going to happen. Queen of Queen of Correct Clubs,Jack of Clubs,Jack of Hearts, Hearts,

10 of Diamonds,3 of Spades (10, 8, 37, 11, 42, 40, 13) 10 of ->(2H,2D, Diamonds,3 of 9S,2C,10H,10D,3S) Spades, 10 of Diamonds,3 of Spades (2,3,4,5,6,40,20) 10 of Diamonds,5 of Diamonds, (13,99,8,56,44,32,789)

Page 26 of 27

10 of Diamonds,3 of Spades, 10 of Diamonds,3 of Spades, 10 of Diamonds,3 of Spades, 10 of Diamonds,5 of Diamonds,

Correct Correct

Probably this will not going to happen. 8 of 8 of Probably Diamonds, of Diamonds, of this will Spades Spades, not going to happen.

2.5.1.3 test procedures

// here describe the setup, the steps for testing etc. The tests were developed using JUnit in Eclipse which performed on a desktop computer that running Windows XP. We have initialized many SevenCardHand objects with various cards value to use for testing. String printValue() We first set up the SevenCardHand object by specified what are the seven cards. Then, we had to call determineValue() to determine the value of this hand and then we called printValue() method to get the result. Then we use assertEquals() to compare the expected and actual outputs. void printCards() We first set up the SevenCardHand object by specified what are the seven cards. The we call this method to see the output. Then we use assertEquals() to compare the expected and actual outputs. void printCC() Simanta Mitra

[email protected]

4-3463

com s 417 SPR 2006

Test Plan and Report

Page 27 of 27

We first set up the SevenCardHand object by specified what are the seven cards. The we call this method to see the output. Then we use assertEquals() to compare the expected and actual outputs.

2.5.2 – EXTRA CREDIT. TEXASHOLDEM CLASS

Amish – Extra Credit 2.2.1 void reset(): We tested this method to see if it resets the dealer data, player data and the game data to null. During our tests we found that the method does not set the dealer data to null. We are confident about our test result since we have conducted all the possible equivalence test classes on this method. int whereIs(String playerName): We tested this method to see if it returns the integer position of the player. During our tests we found that the method returns the proper integer for the respective player. We are confident about our test result since we have conducted all the possible equivalence test classes on this method. 2.2.3 void reset():We first set up players with a particular name and amount, and then this method is called to check if it is able to the player data and the game data to null. We used printPlayerStats() method to compare the expected and the actual outputs. int whereIs(String playerName): We first set up players with a particular name and amount, and then this method is called to check if it is able to return the integer position of the player. We used printPlayerStats() method to compare the expected and the actual outputs.

Simanta Mitra

[email protected]

4-3463