Saturday, July 07, 2007

Removing Canonical Abilities II

So, after a nice little afternoon gaming break (Drakon and Hick Hack in Gacklewack), and a little email, time to get back to work. Well, "work" in quotes, really.
 Oh, one more thing. I'm going to get into the habit of zipping my local files every so often (aka quick & dirty source control). Nothing fancy. We'll see if I remember.
 TNNF = Tested, no new failures.
 
* Update UseAbility to take AbilityID instead of name.
 This should be easy, right? Changes made, let's see...One error (I think if all the tests passed, I wouldn't have believed it anyway) with the oddball "Hit Thumb" ability. Ah - the object I wanted to reuse wasn't available. Moving some lines of code around, and No New Failures.
 
 At this point, I think I can take a different tact. If I remove all of the objects from CCanonicalAbilities, then I can prove that it is no longer used. Let's try the "full steam ahead" approach and comment them all out. If any tests fail, I can re-introduce the abilities to see where the failure was introduced.
 Is this a shortcut? You bet! But if it works, it'll save me some time, and it doesn't take a lot of time to see if it works.
 Well, nuts, I can see that isn't going to work. I have one outstanding reference to CCanonicalAbilities, as used by items. Let's see if I can fix the AddAbility function in Items the same way I fixed it for Characters.
 Knowing what I know now (and knowing that there's only one test), perhaps I can take a few shortcuts, and fix all of the parameters at the same time. Coding...
 Hmm... Item doesn't have the same non-duplicating logic as character. I'll fix that later (and introduce a test for unicity). Cross fingers and test. Errors - ah ha, another undocumented time dependancy in the setup functions. Fixed. NNF.
 
* Test Item Ability Unicity
 Ok, so new test called testItemAbilityUnicity. I'll try to add two abilities of the same name to the Ukelele. Well, I wrote that test, but didn't run it, because the ability I choose to add was (the only ability available to me) Read Book. Which, for a Ukelele, doesn't make much sense. While I was torn between, "It doesn't matter, it's just a test" and "If the test makes sense logically, it'll be easier to maintain", the latter won out. So, now to add it to the test suite. Checking...Excellent. One more passing test. I'm almost at two rows (45 tests and counting).
 Uh oh. That test passed, but I know that it doesn't work, because I didn't implement the duplicate check. The duplicate bug and the "debugPrint isn't a complete description" bug  conspired against me. I'll need to make debugPrint complete, which will make this test fail, and then I can make it pass.
 
Beefing up DebugPrint for Items.
 Done, now the test is failing (accurately). What's nice is that I was able to call the Item's ability's debugPrint function (which, in turn, called the Effect's DebugPrint). All of which use the <ol> html tags, so I get automatic indentation. Hmm.. Now I'm beginning to wish that each of them had its own color (: Maybe I could use some css style tags. That's probably overkill for debug functions, right?
 Now to make it pass. I'm adding a new constant to the class (ABILITY_ALREADY_PRESENT), which should be on other classes as well, but I'll fix them as I find them. Ok, this test passes.
 But wait - there are two other tests that fail now. Probably because I'm comparing debugPrint to strings that need to be updated. Yup. These particular tests are becoming a pain to test. I'd like an "update snapshots" function. I'll add that to my todo list. 
 
testCreateUkelele
 So, first test to fix. Ok, that wasn't so bad.
 
testCreateBook
 A little redundant no? I may rethink them later. Actually, the book should have an ability. Let me update the setup function. Ah ha! The book already has an ability added, but it's not working. Let me dig in to see why....
 Hmm... It's being flagged as a duplicate. So much for that test working. Ah, logic, my old enemy. Fixed...NNF.
 
 It doesn't pay to plan too far ahead. All of my remaining tasks can be replaced by "Remove each reference to CCanonicalAbilities and test after each one.". Let's start, a hash mark for each reference removed without affecting any tests - # Well, I got an error on my second one. testHittingThumbMakesHomerSayDoh needs the canonical object for some reason.
 Actually, in trying to fix it, I've come to the conclusion that this test has too more customization (custom ability, custom effect) than it is worth. I was strugging to find a way to test abilities that were not related to objects, but I don't think I need that right now. As much as it pains me to do so, I'm going to remove the test. Ok, now all remaining tests pass.
 Back to removing references to CCanonicalAbilities. Let's see if CCharacter uses it anymore. Three failing tests, let's make them pass.
 
TestJoeReadingABookMakesHimSmarter
 It looks like the UseAbility function still relies on this canonical object. Actually, I was wrong - the FindAbilityByName function used it. However, I've removed all references to this function (replaced by FindAbilityByID), so we're all set. In fact, I'll rename the function now, and if no tests fail, I'll delete it. All tests say "Go". Delete. Retest because I'm paranoid. Excellent.
 
Back for more gaming! Byebye