Starting from:
$35

$29

Lab 3: Testing Solution

Objective

In this lab, you will expand your skills in developing test cases.

Working alone or in a group of 2, you will create test cases for a program that creates a leader board for a sports league.

You are not required to develop code for the test cases or to develop test input data for your test cases.


Preparation

You are going to help manage the leader board for a local sports league. The teams play against one another and the leader board is created by ordering the teams from most winning to least winning. Speci cally, the rst team on the leader board has the most game wins. If a tie happens between teams then the order of tie-breaking, in order of precedence, is:

most games won most games tied

most points scored by the team

highest di erence of points scored to points lost most games played

lexicographic order of the team names

You will be writing test cases for a class for this problem. The methods in the class are as follows:


public boolean addTeam(String teamName) Adds the given team name as one team in the league. Returns true if the team was added to the league. Returns false if the team is already in the league or if any problem arose with the addition.




public boolean recordGameOutcome(String team1, String team2, int scoreTeam1, int scoreTeam2) Record that team1 played team2 and that the ending score was scoreTeam1 for team 1 and scoreTeam2

for team 2. Return true if the game was recorded. Return false if the game was not recorded or if any problem arose with the recording.









1

public String createLeaderBoard() Create a string that is the leader board for the league. The leader board lists all of the teams in the league in the order of most-successful team to least-successful team, based on game outcomes, as described earlier. Each line of the leader board string is as follows:

team name (use 15 columns)

number of games won (use 2 columns) number of games lost (use 2 columns) number of games tied (use 2 columns)

points scored by the team (use 4 columns)

points scored against the team (use 4 columns) Include one space between each column.

There will also be a header row, with titles Team, W, L, T, +, and -, all right justi ed except \Team".


The league has space for a maximum of 24 teams.

Given the following data for recordGameOutcome (4 method invocations)

"Anchor", "Salty", 15, 12

"RC", "Kitchen Party", 9, 11

"Anchor", "RC", 12, 7

"Salty", "Kitchen Party", 6, 0

We get the following leader board


Team
W
L
T
+

Anchor
2
0
0
27
19
S a l t y
1
1
0
18
15
Kitchen  Party
1
1
0
11
15
RC
0
2
0
16
23


Resources

None required


Procedure

Set-up

    1. Ensure that all in your group understand and agree upon the intention of the problem. Do not make assumptions on how someone will implement a program to solve this problem.







2
Lab steps

Part 1 - Understand the problem

    1. Clarify any ambiguities that your team may have about the problem. Record these clari cations.

    2. Identify the boundary conditions that exist in the problem statement. Record these boundaries.

    3. Outline the type of control ow that any implementation for the problem will need to follow, based on the problem statement. Record these ows.

    4. De ne what would be perceived as the \normal" order in which methods would be invoked for the problem.


Part 2 - Create test cases

    1. Identify a set of input validation tests for each method as well as the expected outcome for each case.

    2. Identify a set of boundary tests for these boundary cases.

    3. Identify a set of control  ow tests.

    4. Identify a set of data  ow tests based on your \normal" order.


Questions

How, if at all, would input validation change if you were getting input from a user interface rather than as parameters to methods?

Explain whether or not boundary cases exist beyond checking the incoming input values. How does the idea of \control ow" change between black box tests and white box tests? Should all permutations of methods result in data ow tests? Explain.

Reporting

    1. In one  le, list

The members of your team.

The clari cations and reporting from part 1. The tests from part 2, divided by test type.

How complete you think that your test cases are. The answers from the Questions section of the lab.

    2. Generate a PDF from the document.

    3. Submit the PDF in Brightspace in the Lab/Lab 3 section of the course page in Brightspace.





3
Assessment

The assessment will be on a letter grade and will re ect how well you broke down the problem, developed tests, and, most importantly, saw how to take the work done in this lab to broaden it to other contexts (the Questions section).

Letter grade
Problem clari cations
Extent
of
the
test
Awareness of the ca-
Awareness  on  using





cases  and  classi ca-
pabilities
of
current
the test structures in





tion (main weight)
tests




broader contexts

A


















(Excellent)
Problem is now clear
Considerable
non-
Demonstrates a good
Clear idea of changes

and
good  assump-
overlapping

tests
sense
for
what
the
to control and
data

tions were made

made for all elements
tests
and
testing
ows for testing






of the
program
and
approaches  can
do.








correctly classi ed
Knows how variations














happen






B


















(Good)
Confusing
problem
Considerable
tests
Demonstrates a good
Knows
that
the

aspects
identi ed.
made

for
the whole
sense
for
the
testing
control or data  ow

Not
all
with
good
problem,

though
approaches. May not
changes
might
im-

conclusions

some

overlap,
and
appreciate
the varia-
pact testing, but not





well classi ed

tions




spelled out well

C


















(Satisfactory)
Main
problem
ele-
Generally
well-tested
Has
a
reasonable
Appreciates that con-

ments  identi ed  for
methods and classi -
sense of how well the
trol  and  data   ow

clari cation

cation is 75%

testing is going

tests can change, but
















unsure how

D


















(Marginal Pass)
Just a few problem el-
A small percentage of
Has a rough idea of
Seeing little change in

ements were clari ed
tests
made
for
most
how well
the
testing
the e ects of the  ows





methods.

Unclear
would be, but some of








if classi cation helped
the logic is  awed








guide them










F


















(Inadequate)
Lots
of
ambiguity
Poor
testing  of
the
Little
sense
on
how
Unsure
of  even
the

remains
about
the
methods
and/or  no
well  testing  is  hap-
context of the ques-

problem


structure to case cre-
pening



tion







ation






































4

More products