test plan template-sayan

8/14/2019 Test Plan Template-Sayan

1/27

com s 417 SPR 2006 Test Plan and Report Page 1 of 27

Black Box Test Plan for COMS 417 Poker Project

Revision History

Version Date Author Change

0.1 09/05/05 SM Initial Document

0.2 01/20/06 JD Altered for COMS 417

GROUP NUMBER 02April Shinatrakool XX% EFFORT

Sayan Ranu XX% EFFORT

Amish M Gangar XX% EFFORT

Simanta Mitra [email protected] 4-3463
mailto:[email protected]:[email protected]


2/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 anindividual 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 createdsix 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 usedequivalence 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 equivalenceclasses 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 willface during an actual operation of the Poker game. Since the methods in the class wont

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 wont expect to make sure that it doesnt failand 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.



3/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 moneythey 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 OVERALLIDEA

// 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 arenegative 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 theTexasHoldEm 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)



4/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 continueplay 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)



5/27


Ans: The overall testing goal is to find the reason behind the bug because while sending aprivate 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) andcheck 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 OVERALLIDEA

// 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 createdsix 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



6/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 thepossible equivalence classes.

getBank() : We have tested this method to see if the bank amount returned is same aswhat 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: positivevalues, 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 thebank 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 andamount, 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 valuetesting 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 onthe 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 aplayer 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 negativevalues.



7/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 moneyavailable, 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 didnt have any statistics available to findout 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 testedall 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 thedeck 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 simulateddealing 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 LISTOFTESTCASES

Group TestCaseDescription Inputs ExpectedOutputs ActualOutputs Comments

getName() The input

tests theequivalence

class of

strings withletters

testPlayer2=

newPlayer("april",-

1000);

april april correct

The inputtests the

equivalence

class of strings withnumbers

testPlayer5=new

Player("1234",

2100100000);

1234 1234 correct

getBank() The inputtests the

equivalence

class of positive

amounts.

testPlayer1=new

Player("sayan",

1000);

1000 1000 Correct



8/27


The input


class of

positive 0.

testPlayer3

=newPlayer("amish",

0);

0 0 Correct

The input

tests thepositive

boundary

values.

testPlayer5

=newPlayer("1234",

2100100000);

2100100000 2100100000 correct

The inputtests the

equivalence

class of negative

amounts.

testPlayer2=new

Player("april",-

1000);

-1000 -1000 Correct

The input

tests the

negativeboundary

values.

testPlayer6

=new

Player("1235",-2100100000);

-2100100000 -2100100000 Correct

addToBan

k()

The input

tests the

equivalentclass of

adding 0 to

the bank amount

Amount in

Bank: 1000

Amount added:0

1000 1000 Correct

The input

tests the

equivalentclass of

adding

negative

amount. Thisalso tests the

equivalence

of a negativeresulting

amount

Amount in

Bank: -1000

Amount added:-1

-1001 -1001 Correct



9/27


The inputtests the

equivalent

class wherethe resulting

amount is 0

Amount inBank: 0

Amount added:

0

0 0 Correct

The input

tests the

equivalent

class of adding a

positive

amount

Amount in

Bank: 0

Amount

added:100

100 100 Correct

The input

tests theboundary

value.

Amount in

Bank: 100000Amount added:

2100000000

2100100000 2100100000 Correct

subtractFr

omBank()

The input

tests the

equivalentclass of

subtracting 0

from thebank amount

Amount in

Bank: 1000

Amountsubtracted: 0

1000 1000 Correct

The inputtests the

equivalent

class of

subtracting apositive

amount from

the bank amount

Amount inBank: 100000

Amount

subtracted:

4600

95400 95400 Correct

The inputtests the

equivalent

class of subtracting

an amount

which is

more thanthe amount

in the bank.

Amount inBank: 1000

Amount

subtracted:2001000

1000 1000 Correct

The input

tests the

Amount in

Bank:

100000 100000 Correct



10/27


boundaryvalue

2100100000

Amount

subtracted:2100000000

The input

tests the

equivalent

class of subtracting a

negative

amount fromthe bank

amount

Amount in

Bank: 0

Amount

subtracted: -1

0 -1 BUG!

Subtractin

g a

negativevalue

from the

banktransfers

money

from thepot to the

bank,

which

shouldnot

happen. It

shouldblock

transactio

ns tryingto

subtract

negativeamounts.

getMoney

InPot()

Random

ValueTesting. The

test starts

with a playerhaving

100000 in

his bank.

The randomamounts

between 0

and 125000are

subtracted

from hisbank

Amount in

Bank startswith: 100000

Amount

subtracted: 0 to125000

Amount put in

pot depends onthe amount

subtracted.

If amount

subtracted isless than or

equal to

amount inbank then the

money in the

pot should be

the initialamount in pot

+ amount

subtractedfrom bank.

Else amount

in pot should be the

When amount

subtractedfrom bank

less or equal

to amount in bank: initial

amount in pot

+ amount

subtractedfrom bank.

When amountsubtracted

from bank

more thatamount in

Correct



11/27


amount. ThegetMoneyIn

Pot() method

is then calledto check if

the money

transaction istaking as

expected or

not.

This tests theequivalence

classes of

positivenumbers

smaller and

larger thanthe amount

in the bank.

The test has

been carriedout 100000

times.

amount it had before the

transaction

took place.

bank: Initialamount in pot.

This tests the

equivalence

classes of subtracting

negative

numbersfrom the

amount in

bank. This

test has beencarried out

10 times.

Should block

the transaction

Initial

amount in

Pot.

Negative

amount

BUG!

Subtractin

g anegative

value

from thebank

transfers

money

from thepot to the

bank,

whichshould

not

happen. Itshould

block

transactio

ns tryingto

subtract

negative



12/27


amounts

2.1.3 TESTPROCEDURES

// here describe the setup, the steps for testing etc.// REPEAT

The tests were done using Junit in Eclipse. There was a setup() method which initialized6 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 thismethod 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. ThegetBank() 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. ThegetBank() 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 theprocess 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 anew 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 theplayer hands as input. This completes the first step of setting up the players to test the



13/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 settingup 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 notseem 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/herbank. 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 andthe 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 thetests 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 paysthem 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 playersimply 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.



14/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. Thismethod 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 tolet 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 itadded 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.


Group TestCase

Description

Inputs Expected

Outputs

Actual

Outputs

Comment

s

Initial

Bank

Amount

-1000 Some error No error

void bet() Inside

domain

- Handle

playerbetting.

No output. Incorrect.

void raise(StringcPlayer, long

raiseAmount)

Insidedomain

20 Add 20from the

current

player tothe current

pot.

Adds 20 fromthe current

player to the

current pot.

Correct.

OutsideDomain

200 Only theamount left

in the bank

should beadded to the

pot.

Throwsexception

Incorrect

Negative

Value

-200 Should not

allow the

money to beadded to the

pot.

-200 added to

the pot and

the player bank money

remains the

Incorrect.



15/27


same.

void fold() Inside

Domain

Player

name

Fold (End

the game ofthe ) player.

Does not fold

the player.

Incorrect.

Thefolded

player is

still ableto add the

money

into the

pot.

void call() Inside

Domain

- Raise the

current player will

0 as the

high blind.

Raises the

current playerwill 0 as the

high blind.

Correct.

void pay() Inside

domain

- Determines

the winnerand pay(s)

them

accordingly.

Unable to

determine thewinner. Just

adds 1 to

handswon .

Incorrect

void

payMoneyOwed()

Inside

Domain

- Pay the

money

owed to theother

players

playing thegame.

Pays the

money owed

to the otherplayers

playing the

game.

Correct

Outside

Domain.

- Throw

Exception

Does not

throwexception,

player

continues toplay the game

even if he/she

does not havethe money

he/she owes

other players playing the

game.

Incorrect

voidgiveAllMoneyBack()

InsideDomain

- Transfer money from

the pot to

the playersbank.

Adds moneyto the bank

but does not

reduce themoney from

the pot.

Incorrect



16/27


void reset()

- Extra Credit.

InsideDomain

- Set theplayers,

dealer,

cards, potsto null.

Does not setthe dealer to

null. Player,

cards, potsset to null.

Incorrect.

int whereIs(StringplayerName)

- Extra Credit

InsideDomain

playerName

Return the position of

playerName

Returns the position of

playerName

Correct


// 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 playerswere 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 thismethod 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 usedprintPlayerStats() 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 actualoutputs.

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 thegame. 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 thismethod is called to check if the method is able to determine the winner and pay him the



17/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 isowed 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 actualoutputs.

2.3 TASK THREE

2.3.1 OVERALLIDEA


// Be sure to include a discussion in what kind of testing strategy was used to test here(equivalent-class partitioning, random, boundary testing, etc.)


The testing is based on the particular method being tested. So, we came up with manySevenCardHand objects with various cards value to use for testing.

void determineValue()

We have tested this method to see if it give the correct hands score or not. We first set

up the SevenCardHand object by specified what are the seven cards. Then we call thismethod 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 thismethod 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 possibleequivalence 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 samecommunity cards (first five cards) to simulate the real poker game situation.



18/27


The methods compared ok if the two hands has different values which came fromdetermineValue(). However, we found a bug when both hands has the same value. Forexample, 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 returnsfalse 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 andboundary testing to test this method which are



We are confident that there is no bug in this method since we have tested all the possibleequivalence 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 areInside 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 doesnt 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 getPlayersCards()We have tested this method to see if it returns the two players cards correctly or not.



19/27




We found a bug when we tested the inside domain. For example, we have set theSevenCardHand object = (20,25,37,11,42,40,46) which the players cards are the last two

cards. It gave a wrong result for 46 in particular since it prints jack_clubs instead of

jack_hearts.


Group TestCase

Description

Inputs Expected

Outputs

Actual Outputs Commen

determineValue()

(*Use

printValue())

Inside

domain

(between 8and 52)

(8,9,10,11,25,51,46) ->

(2D,2S,2H,2C,6S,12C,11H)

four 2s four 2s Correct

(20,25,37,11,42,40,13)->

(5D,6S,9S,2C,10H,10D,3S)

a pair of 10's a pair of 10's Correct

(10, 8, 37, 11, 42, 40, 13)->(2H,2D,

9S,2C,10H,10D,3S)

a full housewith 2's over

10's


10's

Correct

Below

boundary

(below 8)

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

exception

a full house

with 1's over

0's

Probably

this w

not goito happen

Aboveboundary(above 59)

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

a pair of 15'sand anotherpair of 10's

Probablythis wnot goi

to happen

IsBetterThan() Base

hand(this

hand)

(20,25,37,11,42,40,13) ->

(5D,6S,9S,2C,10H,10D,3S)

a pair of 9's

vs. a pair of10's

(20,25,37,11,42,38,14) ->

(5D,6S,9S,2C,10H,9H,3H)

true true Correct

three 5's vs.

pair of 10's

(20,25,37,11,42,21,22) ->

(5D,6S,9S,2C,10H,5S,5H)

false false Correct

a pair of

10's vs. apair of 10's

(20,25,37,11,42,41,48) ->

(5D,6S,9S,2C,10H,10S,12D)

false false Correct

If switch this hand and otherhand then compare

true false Wrongsince t

hand ha

10S, it



20/27


better ththe oth

hand.

Same with

base hand

(20,25,37,11,42,40,13) ->

(5D,6S,9S,2C,10H,10D,3S)

false false Correct

sortByValue() Inside

domain

(20,25,37,11,42,40,46) (46,42,40,

37,25,20,11)

(46,42,40,

37,25,20,11)

Correct

(20,56,25,58,15,46,40) (58,56,46,40,

25,20,15)

(58,56,46,40,

25,20,15)

Correct

Below

boundary

(20,-5,-17,56,13,55,46)

->(-5, -17 are below)

(56,55,46,20,

13,-5,-7)

(56,55,46,20,

13,-5,-7)

Correct

Above

boundary

(13,99,8,56,44,32,789) (100,99,56,

44,32,13,8)

(100,99,56,

44,32,13,8)

Correct

(set card

that > 1

to 100)sortBySuit() Inside

domain

(20,25,58,56,15,40,46) ->

(5D,6S,AH,AD,3C,10D,11H)

(56,40,20,25,

58,46,40)

(56,40,20,25,

58,46,40)

Correct

Below

boundary

(20,5,17,56,13,55,46) ->

(5D,1S,4S,AD,3S,KC,JH)

(56,20,17,13,

5,46,55)

(56,20,17,13,

5,46,55)

Correct

Above

boundary

(13,99,8,56,44,32,789) ->

(3S, C, 2D,AD, JD, 8D, D)

(100,56,44,32,

8,13,99)

(100,56,44,32,

8,13,99)

Correct

(set cardthat > 1

to 100)

isEqualTo() Base

hand(this

hand)

(20,25,37,11,42,40,46) ->

(5D,6S,9S,2C,10H,10D,11H)

Same with

base hand

(20,25,37,11,42,40,46) ->

(5D,6S,9S,2C,10H,10D,11H)

true true Correct

1ast card is

different

(20,25,37,11,42,40,49) ->

(5D,6S,9S,2C,10H,10D,12S)

true true Correct

a pair of 10

but

differentsuit

(20,25,37,11,42,41,46) ->

(5D,6S,9S,2C,10H,10S,11H)

true true Correct

Not enough

cards

(20,25,37,11,42,41) ->

(5D,6S,9S,2C,10H,10S)

Throw

exception

true Wrong.

shouldn

be ablecompare

since it hfewer

cards.

getPlayerCards() Inside

domain

(20,25,37,11,42,40,46) ->

(5D,6S,9S,2C,10D,11H)

(10D, 11H) (10D, 11H)

(20,25,37,11,42,40,46) ->

(5D,6S,9S,2C,10D,11H)

(ten_diamonds,

jack_hearts)

(ten_diamonds,

jack_clubs)

Wrong.



21/27


Belowboundary

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

(empty,queen_spades)

(empty,queen_spades)

Correct

Aboveboundary

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

Throwexception

error Probablythis w

not goi

to happen



The tests were developed using JUnit in Eclipse which performed on a desktop computerthat 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. Thenwe call this method to determine the value of this hand. However, since it is a voidfunction, 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 withmany 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 cardssuit 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 callthis method and use assertEquals() to compare the expected and actual outputs.

Vector getPlayersCards()

We have created a base SevenCardHand object and call this method to get the playerscards. Then we use assertEquals() to compare the expected and actual outputs.



22/27


2.4 TASK FOUR

2.4.1 OVERALLIDEA


// Be sure to include a discussion in what kind of testing strategy was used to test here(equivalent-class partitioning, random, boundary testing, etc.)


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 needto find the equivalence class, which the program cant handle properly. So the majority of

the testing involves generating all the possible equivalence classes and make sure that wedont 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 actualoperation.


Group TestCase

Description

Inputs Expected

Outputs

Actual

Outputs

Comment

s

putMessage()

The inputtests the

equivalence

class of

strings withletters

how r u how r u how r u correct

The inputtests the

equivalence

class of

strings withnumbers

1234 1234 1234 correct

The input

tests the

equivalence

class stringwith

numbers and

I am 2 tired I am 2 tired I am 2 tired Correct



23/27


letters

The inputtests the

equivalence

class stringswith endline

characters

how r u\n how r u\n how r uwith junk

characters

BUG!Whenever

there is an

endlinecharacter

at the end

of the

messageit prints t

he junk

characters

The input


class strings

with tabscharacters

how r u\t how r u\t how r u\t correct



// REPEAT

The tests were done using Junit in Eclipse. First we had to set up the server and client so

that its possible to exchange private messages between the users. To do that, first we ranthe 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 checkedin the chat window of the other player. We could not automate this testing process since it

involves GUI, which can be tested only when its 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 wereused 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.



24/27


First, we came up with many SevenCardHand objects with various cards value to use fortesting.

String printValue()

We have tested this method to see if it give the correct hands 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 calldetermineValue() to determine the value of this hand. Then, we can call this method toget 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.



equivalence classes and boundary.

void printCards()

We have tested this method to see if it print the players cards correctly or

not. We have used equivalent-class partitioning and boundary testing to test this method

which areInside Domain this test with the inputs from 8 59 for a deck of cards (52 cards).




equivalence classes and boundary.void printCC()

We have tested this method to see if it print the community cards correctly or not. Wehave used equivalent-class partitioning and boundary testing to test this method which are





equivalence classes and boundary. However, this method prints six cards which include

one of the players cards while it should only prints five cards.

2.5.1.2 list of test cases

Group TestCase

Description

Inputs Expected

Outputs

Actual

Outputs

Comments

printValue() Inside

domain

(8,9,10,11,25,51,46) ->

(2D,2S,2H,2C,6S,12C,11H

four 2s four 2s Correct



25/27


(between 8and 52)

)

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

a pair of 10's a pair of 10's Correct

(10, 8, 37, 11, 42, 40, 13)->(2H,2D,

9S,2C,10H,10D,3S)


10's


10's

Correct

Belowboundary

(below 8)

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


0's

Probablythis will

not going

to happen.

Above

boundary(above 59)

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

exception

a pair of 15's

and anotherpair of 10's

Probably

this willnot going

to happen.

printCC Insidedomain

(between 8

and 52)

(8,9,10,11,25,51,46) ->(2D,2S,2H,2C,6S,12C,11H

)

2 ofDiamonds,2 of

Spades,2 of

Hearts,2 ofClubs,6 of

Spades

2 ofDiamonds,2 of

Spades,2 of

Hearts,2 ofClubs,6 of

Spades,Queen

of Clubs,

Correct butprint extra

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

5 ofDiamonds,6 of

Spades,9 of

Spades,2 of

Clubs,10 ofHearts

5 ofDiamonds,6 of

Spades,9 of

Spades,2 of

Clubs,10 ofHearts,10 of

Diamonds,

Correct butprint extra

(10, 8, 37, 11, 42, 40, 13)

->(2H,2D,

9S,2C,10H,10D,3S)

2 of Hearts,2

of Diamonds,9

of Spades,2 ofClubs,10 of

Hearts

2 of Hearts,2

of Diamonds,9

of Spades,2 ofClubs,10 of

Hearts,10 of

Diamonds,

Correct but

print extra

Below

boundary

(below 8)

(2,3,4,5,6,40,20) 0 of Hearts,0

of Clubs,1 of

Diamonds,1 ofSpades,1 of

Hearts

0 of Hearts,0

of Clubs,1 of

Diamonds,1 ofSpades,1 of

Hearts,10 of

Diamonds,

Correct but

print extra

andprobably

this will

not goingto happen.

Aboveboundary

(above 59)

(61, 60, 59, 11, 42, 40, 13) of Spades, ofDiamonds,Ace

of Clubs,2 of

of Spades, ofDiamonds,Ace

of Clubs,2 of

Correct but print extra

and



26/27



Diamonds,


Diamonds,

probablythis will

not going

to happen.

printCards() Inside

domain(between 8

and 52)

(8,9,10,11,25,51,46) ->

(2D,2S,2H,2C,6S,12C,11H)

Queen of

Clubs,Jack ofHearts,

Queen of

Clubs,Jack ofHearts,

Correct

(20,25,37,11,42,40,13)->

(5D,6S,9S,2C,10H,10D,3S)

10 of

Diamonds,3 of

Spades

10 of

Diamonds,3 of

Spades,

Correct

(10, 8, 37, 11, 42, 40, 13)

->(2H,2D,9S,2C,10H,10D,3S)

10 of

Diamonds,3 ofSpades, 10 of

Diamonds,3 of

Spades

10 of

Diamonds,3 ofSpades, 10 of

Diamonds,3 of

Spades,

Correct

Below

boundary

(below 8)

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

Diamonds,5 of

Diamonds,

10 of

Diamonds,5 of

Diamonds,

Probably

this will

not goingto happen.

Aboveboundary

(above 59)

(13,99,8,56,44,32,789) 8 of Diamonds, of

Spades

8 ofDiamonds, of

Spades,

Probablythis will

not going

to happen.

2.5.1.3 test procedures


The tests were developed using JUnit in Eclipse which performed on a desktop computer

that running Windows XP. We have initialized many SevenCardHand objects withvarious cards value to use for testing.

String printValue()

We first set up the SevenCardHand object by specified what are the sevencards. 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 sevencards. The we call this method to see the output. Then we use assertEquals() to compare

the expected and actual outputs.

void printCC()



27/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 theexpected 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 datato 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 haveconducted 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 thismethod is called to check if it is able to the player data and the game data to null. Weused 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 positionof the player. We used printPlayerStats() method to compare the expected and the actual

outputs.

test plan template-sayan

Documents