CLUE PLAYERS
Unit Testing
RANDOMNESS
 A student has pointed out that there’s a slight chance for our
random tests to fail.
probability our test will fail
Where:
i is the number of successes required to pass
n is the total number of trials
and p is the probability of occurrence
For the example test,
i=10
n=100
p=1/3
will fail with a probability of 5.28*10^-8
changing i to 1 probability is 1.25*10^-16
Doesn’t mean you can’t test,
but probably good to put all
random tests in separate suite
(especially if using a tool that
automatically runs all tests).
SOLUTION == STRUCT
 Solution has public variables – why?
 What are some pros/cons of approach?
TDD IS HARD! BUT GOOD…




How much design do we do before we begin to code?
Waterfall: Design it all! (slight exaggeration… but not much)
Agile: Just enough
Why? We aren’t good at planning entire systems at once.
 Is it possible to test without knowing the entire program
structure?
 Yes! But it can feel uncomfortable at first.
 Benefit: it can make us produce code that is more modular,
because we need to define/test individual pieces.
LOOKING AHEAD
From a former student
 I do think there would be some value in a class that forces
students into becoming comfortable modifying codebases that
are too big to be reasonable for them to absorb fully . For
example, I use a slightly modified version of emacs on my
mac that disables the window chroming (the maximize,
minimize, close buttons, whatever they're called). I read
enough of the source code to be able to disable it but I don't
have a mental image of the bigger picture of the project (their
data structures, algorithms, how they do things).
It takes some time to get to this point… but being OK with ambiguity/
uncertainty is a good attribute for a software engineering.
EXAMPLE: CREATE SUGGESTION
 Computer needs to make a suggestion which includes a room,
a weapon, and a per son.
 Do we need to know all the details of how the game operates?
No!
 How can we design/test this method without having all the
details????
 Idea: Planning this method helps u s plan the rest of the game.

 Room must match the location of the player. This method is
ONLY concerned with making a suggestion… so we don’t care
how the method is called (i.e., we don’t need to worr y right
now about how player gets into the room)
 How can we know the room? Just pass the location (a
BoardCell) as a parameter.
 Easy to test, and helps us plan what the game needs to do later.
CREATE SUGGESTION, CONT.
 Weapon must be selected. Should be randomly chosen from
all weapons that are not in my hand ( myCards) and have not
previously been seen ( seenCards).
 Do we care how cards were dealt? No, this method assumes myCards
is already set up.
 Do we care when/how we “see” cards? No, this method assumes
seenCards is already set up.
 Similar considerations for Person
CREATE SUGGESTION, CONT.
 Should we return the “suggestion” or store it?
 It seems likely that we’ll want to return it, so that it can be
“handled” immediately – i.e., disproved
 But it’s a quick/easy change between returning vs storing in
an instance variable and providing a getter. So either option is
valid for now.
ONCE THEY PASS, TESTS SHOULD
ALWAYS PASS
 What if we decide later to pass the location/room as
a String, rather than a BoardCell?
 Takes about 2 minutes to update the test from something like:
 makeSuggestion(board.getCellAt(5,7));
to
 makeSuggestion(“Kitchen”);
 Then another 3 minutes to update the createSuggestion code:
 remove “lookup” of room
 replace with parameter
 Run the tests