Game Testing All in One (Game Development Series)
| Did the last window in the Minesweeper test appear the way you expected it to? Explain. | ||
| Pretend that the last Minesweeper window is wrong and should actually match the one shown in Figure 17.8, which you stored after you changed the initial custom values. How would you change the automated test code to check for the "expected" screen instead of the "actual" one? How do you think the log file will change as a result? Make the change(s) and re-run your test to find out. | ||
| Another way to run the test with Minesweeper in the proper state is to set it up before your test runs instead of afterwards. Discuss the pros and cons of each approach. Create updated versions of your test to implement both solutions and run them. Did you change your mind about which is best? Describe any new insights you gained from this. | ||
| Are you happy or sad that you reached the end of this book? Elaborate. |
Answers
| The test put a "2" the Mines field, but when the Custom Field window was opened at the end of the test (see Figure 17.10) the Mines value was 10. Typically, the user would be warned about entering an invalid value. | |
| The captured results produce code that must be manually updated if you want to check for a "desired" result which is different from what was actually captured. Change the VHT code to check for the Mines value of 2 instead of 10. If you scan through the generated code, you will find that after entering the "2" a check is made for "Region 2":
Keys("[Backspace][Backspace]", 0.64, 0.18) Keys("2", 0.79) CompareScreen("Region 2") At the end of the session, the window with the wrong Mines value is captured, represented by the following code:
ClickMenu("&Game;&Custom...", 1.94) CompareScreen("Region 3") In order to check for the screen with Mines = 2 instead of Mines = 10, replace the "Region 3" check with a check for "Region 2" as follows :
ClickMenu("&Game;&Custom...", 1.94) CompareScreen("Region 2") From then on, when you play this script back you will get a Failure on the final comparison until the defect gets fixed. | |
| Establishing the correct game state prior to each test is helpful when you are picking and choosing tests from different features and running them one after another. Each test carries the responsibility to set itself up properly. Establishing the correct game state after your test can also serve this purpose once a proper game state is established by some other means prior to running the first test. The post-test cleanup has the benefit of leaving the test machine in some kind of usable state. Tests that only "clean up" before they run could leave a mess behind if someone needs to use the machine for manual testing purposes. In either case it's important to have a consistent policy. Doing a pre-test cleanup after the previous test has done a post-test cleanup is a slight waste of time. What's worse is when a test that doesn't clean up after itself is followed by one that does not do a pre-test cleanup. | |
| Ideally, you are happy because you have learned much from this book that you will put into practice, and you are sad that there aren't any more fun testing things to learn from this book. |