This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: EECS 280 F07 Discussion Notes - Week 7 October 26, 2007 More testing (it never goes away) Testing is absolutely critical to success in this class. In fact, there is a saying that goes: if the code hasn’t been tested, it doesn’t work. With that in mind, let’s look at a few examples for testing project 3. Project 3 - Controlling the game The dice rolling in project 3 is random, so you might wonder how you could ever get reliable test cases out of the project. In reality, the dice rolling is entirely predictable (it generates the same sequence of rolls every time you run the program), but it’s still somewhat out of our control. Of course, to test the project, we need to control the dice, but how? It turns out that the answer is pretty simple: we simply supply an alternate version of roll die (), the function used to simulate random dice rolls. roll die () is declared in dice.h and defined in dice.cpp, so all we need to do is create our own .cpp file that #includes dice.h and implements roll die (). In altdice cin.cpp, dice.test1.cpp, and dice.test2.cpp (see handout), we provide some example implemenations. Then when we compile, we put one of our .cpp files on the command line instead of dice.cpp. The first implemenation (altdice cin.cpp) prompts the user for each roll in sequence. Note that if the user enters a non-integer or something that’s not in the range 1-6, we prompt and read again until they give a proper answer. The second implemenation (dice.test1.cpp and dice.test2.cpp) stores the dice rolls in an array of enters and simply returns the next integer in the array each time roll die () is called. The first version has the advantage that it doesn’t need to be recompiled every time you want to change the dice rolls. You can still do automated testing with it by putting the numbers in a file and feeding it to the project with input redirection (i.e., ./p3 < infile ). Notice, however, that when you write the input file, you will have to know how many times 1 roll die () will be called, but you should know that anyway because you will be carefully planning your test cases. One nice aspect to the other approach, though, is that it allows us to document each roll with comments, which is not possible when putting the rolls in the input file (at least, not without some more complicated parsing of the input, which we want to avoid while testing). We’ll use the latter approach for the following test cases, though you could create the same results by putting the numbers in an input file instead. (Note that our method requires one dice test.cpp file per test. Testing Jail-related behavior There are three conditions that cause a player to be sent to Jail: 1) landing on Go to Jail, 2) being directed there by an absolute movement card directive, or 3) rolling doubles three times in a row. We want a test case to check each of these (though the first two are similar, so we can combine them), and we’ll also add some testing for the “escaping from jail” logic.so we can combine them), and we’ll also add some testing for the “escaping from jail” logic....
View Full Document
This note was uploaded on 04/04/2008 for the course EECS 215 taught by Professor Phillips during the Winter '08 term at University of Michigan.
- Winter '08