Extreme Programming in St Louis, MO

Extreme Programming in St Louis, MO

We had a meeting Monday night and did some testing of "untestable" code.
Brian Button briefed us with a simple problem he'd run into and presented us with a sample project to tackle.
The problem was not so overwhelming that you got lost in what it was that was trying to be accomplished by the code, but you could focus on the testing part.
(It was a simple problem dealing with putting together a string based on the AppDomainName.)

We broke up in to small groups. Mixing up some with people we don't usually work with. (Which I really liked.)

The first thing we had to do was put together a VS2003 C# project. The VS2005 solution format isn't compatible with VS2003.

Brian had already briefed us that two of the tests weren't passing and it was obvious that this should be the case. However, the fun part was that two of the test may or may not pass depending on the test runner you ran them with. Initially, NUnit was passing two of the test and ZaneBug was failing all of the tests! It turns out that NUnit creates an AppDomain with a much longer name than does ZaneBug. I liked being able to switch between the two different test runners and see how things were behaving.

    The interesting things for me out of the evening:

  • My team got to see TDD on "untestable" code.
  • We got to practice mob/pair programming.
  • We got to interact with other people that are doing/working towards XP.
  • The different groups came up with 3 or 4 other solutions than what Brian had coded.
  • Although we didn't go this route, I saw where an interface would have been handy in creating a mock object.
    Things to keep the same in the future:

  • Mixing up the groups with people that don't usually work together.
  • Simple problems that let you focus on the TDD as opposed to the algorithm, etc.
  • Open networked environment
  • Brief presentation to entire group
    Things I'd do different:

  • Let someone else drive?
  • Have beginning/starting point code available printed.
  • Give TDD guidance up front or at the end, but not during session. (Only answer the business rules questions.)
    Maybe preferably at the end? I'm pretty sure we would have implemented things differently if we didn't know how Brian had implemented it.
    Although, we did discuss the various alternatives and their pros-cons and opted for the route he went. Partly for the sake of time, too. But once you had an inkling of how it was solved it seemed a bit like being told the ending to the movie.

Overall, I enjoyed the meeting and I look forward to future meetings and "hands on" nights.