Today I spent most of the most of my morning and afternoon honing my TDD skills with Rob Cooper. Whilst none of the work we did was particularly earth-shattering it was great to delve in code and discuss at length. We tackled a TDD Kata in depth rather than discussing the 'form' elements we concentrated on discussing how the design emerged and the different approaches to testing. We had a few technical issues and ironed most of them out but I wanted to outline the setup as it seemed fairly easy to arrange.
Remote Pair Recipe
- IDE of choice - (helps if these match)
- Git - (or other DVCS)
- GitHub Account - (or other hosted service)
- Skype/GTalk/Live Messenger - for Audio Comms
- MS SharedView - see what the other pair is doing
MS SharedView deserves a special mention here as it worked extremely well for screen sharing.
Check your setupBefore starting make sure you can both access and commit to Github. This is the place where you are both going to be passing your code back forth to. Make sure your equipment works (someone in this pair had a crappy mic in his headset - no names mentioned (*cough* - me)). This slowed us down and upset flow a little. Thankfully the other pair was not blameless. If you are going to use other tools agree what they are, including version, before the event so you don't have to spend time scrabbling around the internet for requisite software.
Have a planDo not go into a session unprepared. Without a plan a session will lose direction. I think we were over-prepared with things to do but its better to have more than less.
Don't be scaredHaving someone watching your every keystroke may seem like a daunting thing but
Don't be offensive eitherThere are many ways to convey that your pair has not removed the duplication in that class other than by comparing his intellect to that of an amoeba. Pick a nicer one.
Swap driver-navigator oftenRob and I swapped mid-scenario in our TDD session. I would red-green (to the simplest possible case) then Rob would grab the session add a further test and refactor. We thought this was a nice way of doing things as we both had our input in creating the feature. I would make the fixture and pass it over to Rob as tested. Rob double checks with a further scenario and makes the call to refactor.
Embrace your differencesRob and I had a slight difference in our approach to testing. We stopped and talked about it afterwards but it was not a problem in this case as the code was 'throw away'. The issue may have been more pressed if we wanted to keep the code.
Take breaksI'm ashamed to say that even though Rob and I are both Pomodoro Technique practitioners we took 1 break in the multi-hour session. This was wrong. I found that towards the end of the session I was losing concentration. With pairs I think this especially important due to the intense focus you have with two of you.
WorkflowWe approached the exercise like so:
- Driver picks feature
- Driver writes test.
- Driver passes test.
- Driver commits and pushes to GitHub
- Navigator pulls from github
- Navigator becomes Driver
- Driver adds 'confidence' test and refactors.
- Go to 1.