Bits of my experience moving to an XP process.  --JasonCole

'''24 Apr 02--Introducing story cards to the client'''

Went to my client today after a series of emergencies, two of which gave me tasks to do.  We talked yesterday about the client right/responsibility to prioritize stories.  I had the two emergencies on cards, with another card, roughly:  Get buglist up-to-date and on cards, produce estimates.

I walked up and waved the three cards at her.

"I think I'm going to get another session on XP!"

"Yep.  I've got your two emergencies, here, and another task I have from this morning, to get our bug list up-to-date and costed.  What do I do first?"

"You can't do seven things at once?  C'mon, multitask!"

"I can do two, if I get to not think.  If I'm programming, there's nothing left but breathing and scratching my head.  Sometimes I forget breathing."

"Okay, do this one, then finish the bug list, and I really will prioritize it tomorrow morning.  Then the other emergency."

My thought bubble:  Wow, planning before panic.  This might work pretty well.

"Excellent, I'll do it that way, thanks."

"Before you go, I've got another thing--I noticed today, during training, that we could use an easier way to get the calendar back to today--Almost everything leads us back to needing today's schedule."

I pulled a blank card from my pocket, carefully not smugging it up, and wrote that down.


-----
'''25 Apr 02--Adding unit tests to legacy ASP'''


Good news, AspUnit exists.  Bad news, it's not quite the same API as the general family of *Unit harnesses.

I'm stubbing my toes on a couple of things:

First, the only method of inclusion is a literal "put this file here at compile-time."  If my file includes A and B, and they each include C, the compiler goes batsqueak on me.  I'm not sure how to write my tests so I can run (multiple/all) test suites with one click.  This will become important to solve soon.

Second, one of ASP's primary features is a quick thunk (two characters) between code and immediate HTML output to the client's browser.  ASP doesn't, so far as I've found, have a way to view the buffer being built, even though it's buffered until page completion by default.

Not a technological limitation, but a fact of my codebase is few subs/functions/methods.  Often a display-and-process form page will handle the two cases in the two branches of one file-long If-Else statement.  This leaves me with a wealth of code that isn't very unit testable.

So, I've found myself doing a couple of categories of refactorings, without tests.  More exactly, where my UnitTest software is EyeballUnit.

Category one, granulate and defer output
	* Extract chunk into new subroutine
	* Refresh browser, look at output, hope I spot any breakage.
	* Change thunks and equivalent 'Response.Write()' calls to appends to a local string var, which I Response.Write() just before leaving the sub.
	* Refresh, eyeball...
	* Change sub to function, return temp string var from function, change calling code to store or write return value as needed.
	* Refresh, eyeball...

Once I've done this, I have to try hard to resist refactoring in trickier ways.

Category two, relocate bits to be includable
	* Create new file, #include it from main page
	* Refresh, eyeball...
	* Move functions to new file
	* Refresh, eyeball...
	
Once I'm there, I can start separating the the calculations and the DB usage out of the HTML wrapping code, and write some tests, including, I hope, one that will expose what I'm here to fix in the first place.

I'll need to write more DB support fns so I can setUp() DB stuff reliably, before those tests are going to be good to me...

"Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!" The Red Queen, from ''Through the Looking-Glass'' by LewisCarroll


-----