Better tests
Fixing tests
As mentioned earlier, many of my tests aren't as specific as they could be. The tests check to make sure that something has changed, but not necessarily what. I'm going to fix that now.
First, I need an easier way to get the value of a Character's statistic, as that's what I want to compare most of the time. I've added a member function FindStatisticValueByName(strName) to the Character class. I can make use of this function in the sibling method UseAbility.
Ah good. All the passing tests prove that I've made this change without breaking anything.
Note that the functions that test to ensure that the object hasn't changed don't need to be fixed yet. However, comparing the output of DebugPrint isn't quite ideal. It would be better to add an Equals(objOtherObject). But that's for another refactoring session.
The comments below are the results that each test displays. The "12 is the same as 12" is the output from the call to assert (observed value == expected value).
TestJoeReadingABookMakesHimSmarter
Joe read the book. Good. His intelligence was 11 and should now be 12. 12 is the same as 12. Done.
testIndirectlyMakingHomerSmarter
Homer's intelligence was 3. 4 is the same as 4.
testIndirectlyMakingLisaDumber
Whoops - failed the first time, I was copying and pasting the "smarter" code, not the "dumber" code. Easy fix. Lisa's starting Intelligence is 18. 17 is the same as 17.
testMakingHomerSmarter
Homer's starting intelligence is 3. 4 is the same as 4. One more to go.
testMakingLisaDumber
Syntax error. Then, with simple elegance, 17 is the same as 17.
ToDo list--
I get to take that off of my todo list as a reward. What next? Well, I think the big question is: Do I have enough scaffolding to start to create game logic? And, if so, how do I organize my files to make things as easy as possible?
I know that, eventually, I want to take all of my objects and put them into their own files. But, it's really convienent (read: Intellisense works) when the object definitions are inline. I think I'd like to have a shared file (include\shared.asp?) that I can use for both the test page, and the final game page. Then I can add two "dumb" presentation pages, one for test.asp, and the other for game.asp.
Essentially, I'm doing an Extract File refactoring (:
Moving Code
I'm moving one block at a time and resting. Constants... done. Test Functions...done. Classes .... done. Great.
What about include files? Not needed by game.asp, so it stays in test.asp.
TestAll? Not needed by game.asp, so it stays in test.asp.
So, I'll have a temporary area at the top of shared.asp for whatever I'm currently working on. Once I'm happy with that code, it gets moved (usually to successful_tests.asp). Game-specific code (or test-specific code) should get relegated to separate files.
One concern, of course, is how do I test the stuff that's only in game.asp? Or, is it acceptible to have presentation code that is not under test? For now, I think it's okay to keep "dumb" presentation logic untested. I hope I don't have to eat those words later.
As mentioned earlier, many of my tests aren't as specific as they could be. The tests check to make sure that something has changed, but not necessarily what. I'm going to fix that now.
First, I need an easier way to get the value of a Character's statistic, as that's what I want to compare most of the time. I've added a member function FindStatisticValueByName(strName) to the Character class. I can make use of this function in the sibling method UseAbility.
Ah good. All the passing tests prove that I've made this change without breaking anything.
Note that the functions that test to ensure that the object hasn't changed don't need to be fixed yet. However, comparing the output of DebugPrint isn't quite ideal. It would be better to add an Equals(objOtherObject). But that's for another refactoring session.
The comments below are the results that each test displays. The "12 is the same as 12" is the output from the call to assert (observed value == expected value).
TestJoeReadingABookMakesHimSmarter
Joe read the book. Good. His intelligence was 11 and should now be 12. 12 is the same as 12. Done.
testIndirectlyMakingHomerSmarter
Homer's intelligence was 3. 4 is the same as 4.
testIndirectlyMakingLisaDumber
Whoops - failed the first time, I was copying and pasting the "smarter" code, not the "dumber" code. Easy fix. Lisa's starting Intelligence is 18. 17 is the same as 17.
testMakingHomerSmarter
Homer's starting intelligence is 3. 4 is the same as 4. One more to go.
testMakingLisaDumber
Syntax error. Then, with simple elegance, 17 is the same as 17.
ToDo list--
I get to take that off of my todo list as a reward. What next? Well, I think the big question is: Do I have enough scaffolding to start to create game logic? And, if so, how do I organize my files to make things as easy as possible?
I know that, eventually, I want to take all of my objects and put them into their own files. But, it's really convienent (read: Intellisense works) when the object definitions are inline. I think I'd like to have a shared file (include\shared.asp?) that I can use for both the test page, and the final game page. Then I can add two "dumb" presentation pages, one for test.asp, and the other for game.asp.
Essentially, I'm doing an Extract File refactoring (:
Moving Code
I'm moving one block at a time and resting. Constants... done. Test Functions...done. Classes .... done. Great.
What about include files? Not needed by game.asp, so it stays in test.asp.
TestAll? Not needed by game.asp, so it stays in test.asp.
So, I'll have a temporary area at the top of shared.asp for whatever I'm currently working on. Once I'm happy with that code, it gets moved (usually to successful_tests.asp). Game-specific code (or test-specific code) should get relegated to separate files.
One concern, of course, is how do I test the stuff that's only in game.asp? Or, is it acceptible to have presentation code that is not under test? For now, I think it's okay to keep "dumb" presentation logic untested. I hope I don't have to eat those words later.
posted by FlyingSheep @ 10:29 AM
0 comments
