Pair Programming

Today was a great day! After spending most of yesterday and this morning chasing down a deployment bug that turned out to be a mis-registered COM object (worked in DEV, but not in QA) I spent the rest of the day pair programming with a new employee. We decided as part of his orientation that we should develop an extension to the ConfigurationSettings.AppSettings to be aware of the environment the code was running in. This has been a desired feature for some time now as we spent too much time twidling config files after deployment. After consulting with a couple of other developers on the design we plowed ahead, test-first.

I prefer to develop with an intentional programming style, sometimes to the detriment of test development. My excuse being that how do I know what I should test if I don't know how my client code wants to use the functionality I'm trying to develop. My partner parried with the idea that tests can be refactored as the design progresses, to which I had no argument. My only instance was that we developed tests that mimiced the client code as much as possible and only wrote more detailed tests after the real design started to emerge.

The only real challenge was when we wanted to write tests against specific environment settings. We had designed the component to look up the machine name in a list to see which environment the value should come from. But for testing purposes we would have no idea what the machine name would be since any developer could run the tests. We talked about creating a mock object to simulate the machine name lookup, but the overhead of creating an interface and two instances or a class and a subclass seemed like overkill. We settled on a protected method that lets us set a default machine name if the machine name was not in the list. We made it protected since we didn't want to see this method called from any production code as the desired behavior was to throw exceptions if the config file wan't set up correctly.

We had the component working with all the test running in ~3 hours. We took a break for lunch and to catch up on other happenings before integrating our new functionalitly into an existing application. My co-worker also spent some time looking for a way to import an xml fragment into a config file with no luck. I know I've seen this in online examples somewhere, but was unable to put my finger on it.

During the afternoon we integrated the new config component into the application and made only one small change to the component. We changed the testing default machine to the default environment and made the method public so tests in the applications could specify which environment to use for testing. We did make the method name explicit to its testing purpose 'SetDefaultEnvironmentForTesting'.