Past ID vs Object hurdle
NNF = No New Failures.
Relative Time
It's only been a week ...
Interruption
Sometimes I'm glad that my last name is difficult to pronounce. It makes telemarketers easy to identify.
As I was saying
It's only been a week, but it was a long and fun-filled week. A good friend from out of town stopped by to visit for a few days, I celebrated my birthday, and I got a lot of cool new games. I also figured out how I want to proceed with my Object or ID problem.
objCharacter.CreateAndAddItem
This new function will create a new Item, load it with the given ItemID, and then delegate to the existing AddItem function. I'm not sure it belongs in the objCharacter class, but it can start off there and move later. I'll take this in small steps.
objItem.LoadByID
This will eventually use the database, but for now, it'll be hardcoded to set certain properties with a select/case switch. I've created a failing test for it. testLoadStagePass (bringing my total up to 3 failing tests, which may be the most at one time). Interestingly, perhaps instead of creating a new test, I can use testCreateStagePass instead? Let me try that.
Ok, now the old test is still passing, but I know that the ID is not being saved correctly. This is a fault of the test - I'll update the Item.DebugPrint to expose its ItemID, and then the test will no longer pass.
Codependance
One of the theoretical (philosophical?) objections I had to test-driven development is that it seems to only be one layer deep. That is, you write tests that verify your code, but what verifies the tests? Who watches the watchers? Should you write tests for your tests first? If so, where do you begin?
As it was explained to me (and I'm now beginning to understand with experience), tests are not on a different level than code - they are both on the same level, and depend on each other. The code validates the tests, and the tests verify the code.
Back to Items
All three of my item tests (Ukelele, Stage Pass, and Book of Knowledge) are now failing. My "automatically update snapshots" task raises in priority on my todo list. Starting with Stage Pass, the test now have the right value (including the ID of 100). This test still fails, of course, because my Load function isn't complete. Completed Load function... 1/4 failing tests fixed. NNF
Next is testCreateUkelele. 2/4 fixed NNF. testCreateBook. Fixed NNF. Back to original 2 failing tests.
Note that Item.LoadByID does not do everything necessary to load the Book of Knowledge. But, for now, that's okay as this function isn't used for the Book of Knowledge. It's not used for Ukelele yet either, but by the time it is used, it will probably be a real database function.
objCharacter.CreateAndAddItem
Next step is to create and test this function. As before, I can simply re-write an existing test function (such as testGiveHomerStagePass). Done... NNF. Now, I've really got two different tests here - one which is give Homer a stage pass directly, and the other is give him a stage pass by way of an effect. At this point, I'll copy/paste the existing function (which does not use the effect), and rename it.
testGiveHomerStagePassViaEffect
Ok, now when this test fails (but the other one passes), I know that something is wrong with the effect. And right now, the effect doesn't do anything, but that will be fixed shortly...10 keystrokes later - nuts, the test still doesn't pass. Although, and this is nice, I know that the objCharacter.CreateAndAddItem function works, so I can narrow down my debugging. Ah ha! A single Debug.Print call reveals that I'm applying the wrong effect (Take Ukelele, not Give Stage Pass). Easily fixed and now...Success!
testCreateReactionToUkelelePlaying
Ok, here's the last step - let's make Homer play the Ukelele to the stage manager, and confirm that he gets the stage pass. It'll have to wait for next time, though. In the meantime, only one failing test.
Relative Time
It's only been a week ...
Interruption
Sometimes I'm glad that my last name is difficult to pronounce. It makes telemarketers easy to identify.
As I was saying
It's only been a week, but it was a long and fun-filled week. A good friend from out of town stopped by to visit for a few days, I celebrated my birthday, and I got a lot of cool new games. I also figured out how I want to proceed with my Object or ID problem.
objCharacter.CreateAndAddItem
This new function will create a new Item, load it with the given ItemID, and then delegate to the existing AddItem function. I'm not sure it belongs in the objCharacter class, but it can start off there and move later. I'll take this in small steps.
objItem.LoadByID
This will eventually use the database, but for now, it'll be hardcoded to set certain properties with a select/case switch. I've created a failing test for it. testLoadStagePass (bringing my total up to 3 failing tests, which may be the most at one time). Interestingly, perhaps instead of creating a new test, I can use testCreateStagePass instead? Let me try that.
Ok, now the old test is still passing, but I know that the ID is not being saved correctly. This is a fault of the test - I'll update the Item.DebugPrint to expose its ItemID, and then the test will no longer pass.
Codependance
One of the theoretical (philosophical?) objections I had to test-driven development is that it seems to only be one layer deep. That is, you write tests that verify your code, but what verifies the tests? Who watches the watchers? Should you write tests for your tests first? If so, where do you begin?
As it was explained to me (and I'm now beginning to understand with experience), tests are not on a different level than code - they are both on the same level, and depend on each other. The code validates the tests, and the tests verify the code.
Back to Items
All three of my item tests (Ukelele, Stage Pass, and Book of Knowledge) are now failing. My "automatically update snapshots" task raises in priority on my todo list. Starting with Stage Pass, the test now have the right value (including the ID of 100). This test still fails, of course, because my Load function isn't complete. Completed Load function... 1/4 failing tests fixed. NNF
Next is testCreateUkelele. 2/4 fixed NNF. testCreateBook. Fixed NNF. Back to original 2 failing tests.
Note that Item.LoadByID does not do everything necessary to load the Book of Knowledge. But, for now, that's okay as this function isn't used for the Book of Knowledge. It's not used for Ukelele yet either, but by the time it is used, it will probably be a real database function.
objCharacter.CreateAndAddItem
Next step is to create and test this function. As before, I can simply re-write an existing test function (such as testGiveHomerStagePass). Done... NNF. Now, I've really got two different tests here - one which is give Homer a stage pass directly, and the other is give him a stage pass by way of an effect. At this point, I'll copy/paste the existing function (which does not use the effect), and rename it.
testGiveHomerStagePassViaEffect
Ok, now when this test fails (but the other one passes), I know that something is wrong with the effect. And right now, the effect doesn't do anything, but that will be fixed shortly...10 keystrokes later - nuts, the test still doesn't pass. Although, and this is nice, I know that the objCharacter.CreateAndAddItem function works, so I can narrow down my debugging. Ah ha! A single Debug.Print call reveals that I'm applying the wrong effect (Take Ukelele, not Give Stage Pass). Easily fixed and now...Success!
testCreateReactionToUkelelePlaying
Ok, here's the last step - let's make Homer play the Ukelele to the stage manager, and confirm that he gets the stage pass. It'll have to wait for next time, though. In the meantime, only one failing test.
posted by FlyingSheep @ 3:33 PM
0 comments
