Session recap part 2 Aug 22

Jordan had to leave early, so first Jordan paired with Adnan working on the Simple Preview story which is a preview of what the processed code will look like once macro expansion has run. I was the odd-one-out working to create Basic Standard Error Macros that the eventual user can employ using the tool we’re writing. This story is not scheduled until the next iteration, but we had 2 cards scheduled, 2 pairs, and me, so that was the next thing to work on.

I also stuck my nose in on Jordan and Adnan to reiterate the advice Ward gave us last time we werking on a UI component which is to make the code do everything we can think of that the UI will need under TDD first, then implement the UI. Since Sam already had a successful spike expanding code into a new Access database project, the task looked trivial – when will we learn :)

Working on the error macros, I made some good progress. I came up with an idiom that provides a logical place for for user-defined cleanup code without the need for some kind of fancy user overridable code block, and allows the use of a simple parameter replacement to distinguish between the 2 main types of error handling code without needing macro groups, mutually exclusive seedings, etc.
Partly based on my nosey advice, Jordan and Adnan started working toward a test that would create an instance of a particular form, treating it just like any other class, pass it a database name and a module name, call a method to display the output, and check the contents of a text box on the form to see if it had the right text, and they made some progress in that direction.

Jordan had to leave, and since Sam and Kristie were just getting into a groove, I took Jordan’s place with Adnan. I must admit, I wasn’t pairing well - more like coding and telling Adnan what I was doing, though I did take some of his advice on how to proceed. In the future, I’ll try to give up the driver’s seat when I see this happening, and I suggest we all try the same thing to see if it helps.
When I sat down with the code for the Simple Preview, I realized that my advice had probably been wrong. What we really needed first was just a way to supply an Access database name, a procedure name, and get the expanded code text. We started to write that test, and I realized that there was not already a test to simply get the expanded text of a named module from an Access project. We commented out the test in progress, and wrote a test for parsing the module from the project by name. We then realized that, although our tests were opening Access projects to pass references to the tests, the metacode system had no ability to do that itself, so we needed that first.

At this point, I noticed that we had started a test, commented out to write a prerequisite test, then did it again with a pre-prerequisite task. I thought this seemed odd, so I consulted with Sam, and he thought it seemed like a perfectly good thing to do, so we kept going with it. We got the first test passing, then the next, then were back to the test we started with, then got stuck, and didn’t get unstuck until I was cleaning up myself 5 minutes after everyone else left, atwhich point, the test finally passed – sorry you weren’t there to see it go, Adnan.

The problem had been our confusion over where the macros get parsed out of the module. We had thought we needed to invoke ParseMetaCodeFromProject before trying to parse the text for a single module using ExpandModuleFromText, but ExpandModuleFromText actuallu calls ParseMetaCodeFromProject, and trying to do it twice gave us a collection key conflict. I think this should be refactored first thing next week because it’s counterintutive, and it means having to parse the entire project once for each module to be expanded. Also, clsMetacodeSystem is simply ending up doing too many unrelated things, and needs to be broken up.

At the very end of the session, we realized we still had loose ends to tie up. Code had not yet been integrated, wrap-up discussions had not taken place, etc. In the future, we’ll need to bring coding to a stop -before- everyone has to leave, so we can take care of these things. I was left to integrate the changes alone (which was absolutely trivial). I added the tests from the code Adnan and I were working on to the copy Kristie and Sam had been working on, hit compile, and copied code from the other project until the compile succeeded. After that, the tests ran and passed. It took about 10 minutes.

In doing the integration above, I ran into something interesting. Although Sam and Kristie had left their code passing all tests, it actually did not compile. This has to do with VBA’s “feature” that allows you to run partially compiled code, and compiles uncompiled code if/when it gets invoked. Since the code that would not compile was dead code, ready for removal, none of the tests complained.

A note regarding Sam’s concern about 2-week iterations: Just because we don’t have an iteration-planning meeting, doesn’t mean we shouldn’t have a status meeting, just that we would not do a full card spread, etc. I understand that it’s typical for XP teams to have weekly meetings within an iteration, and assess how things are going. At this point, if the iteration looks to be ahead or behind, the customer can decide what cards to push out or drag in, etc.