TDD Katas and/or Pair Programming remotely

10 views
Skip to first unread message

Chris F Carroll

unread,
Dec 11, 2025, 7:12:56 AM (13 days ago) Dec 11
to xp-manchester
Does anyone have any tips or experience on doing TDD katas when everyone is remote?

My current team hopes to make a first attempt tomorrow having minimal prior experience of TDD or effective pairing, and no prior experience of doing katas.

My expectation is that it's going to be like doing it not-remotely but harder and not as good. Maybe there's something that can be done differently?

I'm expecting 4 of us, so I am thinking that starting in one group of 4 might be better than splitting the meeting into 2 pairs. Our tech is MS Teams & Visual Studio.

Any wisdom greatly appreciated!

Chris

Christoffer Gamrath

unread,
Dec 11, 2025, 7:43:37 AM (13 days ago) Dec 11
to xp-man...@googlegroups.com
I usually create a repository with with a test runner already set up and the kata description as a text file. In advance, I ask the participants to clone the repo, run the tests, add their name to the readme, and commit and push. This is to confirm that the project can run on their computer and they have access to the repository, so we don't have to spend time debugging that once we start the session.

To rotate driver during the session, current driver commits and pushes. Then the next driver shares their screen, pulls the latest changes, and runs the tests to confirm that they are in the same state as before. Then we can proceed with the kata.

I prefer screen sharing over tools like VS Live Share or Code With Me (IntelliJ). 1. They do not share other things that might be going on on the driver's computer, like a web browser; 2. they don't even share everything that's happening on the driver's computer inside the IDE (e.g., tooltips or popups won't appear for other participants); 3. at least in Code With Me, the automated refactorings are not available for "guests" (at least they weren't last time I used it).

Even mediocre screen sharing like Teams is OK and can be good enough, but something like https://tuple.app/ is better (also pricey). If using Tuple and you have sufficiently low latency, I would even consider running the IDE on one machine and letting the driver use it remotely. With Teams, I would recommend everyone runs the IDE locally and shares their screen.
--
You received this message because you are subscribed to the Google Groups "xp-manchester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xp-mancheste...@googlegroups.com.

Rob Whittaker

unread,
Dec 11, 2025, 7:43:42 AM (13 days ago) Dec 11
to xp-man...@googlegroups.com
I recommend the shopping cart kata and noisy animals

I did the shopping cart kata at XPMan back in the day

Noisy Animals is better as a group discussion

—Rob

Stephen Taylor

unread,
Dec 11, 2025, 7:52:29 AM (13 days ago) Dec 11
to xp-man...@googlegroups.com
Hey Chris,

Just to add to Rob's and Chris's comments, I've done a lot of remote pairing.  Not katas, but on features and work targeted for production.

I found TeamViewer to be the best.  Teams can be a bit annoying and laggy and not register gestures and mouse scrolls and things like that.  If you are using office wifi, make sure your network permits the traffic to whatever screen sharing software you use.  It's worth having a trial run of the setup in advance to make sure everything works properly, including audio/video.

Otherwise, it's pretty much as good as doing it in person.

If you have any other questions, feel free to drop me an email and I'd be happy to chat.

Ste


The Mr Tortoise

unread,
Dec 11, 2025, 7:56:14 AM (13 days ago) Dec 11
to xp-man...@googlegroups.com
I find remote has a ton of advantages

E.g. you can share a session 
The problem is that it's a bit harder talking over each other.

But when it's going well you can have people working in 2 connected places at once whilst  under test 


It's defo worth practicing and iterating with short sessions and plenty of retros

Larger groups suffer from distraction slack and emails

I have had to address that head on a few times

Also bear in mind  if you are like me you might be able to go 9 hours but most are fucked after 1 at most. Highly recommend retros every 40 mins. 

Agree coffee break protocol plan in lunch times ban meetings during sessions

Paul D'Ambra

unread,
Dec 11, 2025, 10:50:15 AM (13 days ago) Dec 11
to xp-man...@googlegroups.com
Screenshot 2025-12-11 at 15.48.25.png
Coincidentally we just had a few in-person hackathons and a remote hackathon for folk that couldn't travel
And the remote hackathon report was that Tuple was the best tool they tried
(and Danilo is hard to please)

Christopher Gunn

unread,
Dec 11, 2025, 12:30:35 PM (13 days ago) Dec 11
to xp-man...@googlegroups.com
I’ve used Pop.com for remote pairing (using the desktop app). I even found it better than Tuple (the fact that it’s free for now I’m sure influenced our decision). I rate it high enough to use it in remote interview situations.

In terms of setup I agree having a repo set up beforehand is very beneficial. 

For 4 people I’d keep it to one group. If you want to run a workshop with multiple groups I find that Teams has that covered very well via its concept of rooms. As the facilitator you can jump between rooms, bring people back to the main rooom at the end and also issue announcements. Even in that situation though I’d have each room use Pop.com. 

Sometimes katas get feedback that they are artificial - something that works in a kata people have trouble applying to the codebase they work with daily. In this case what can work is talking through some principles and then applying them to the ‘real’ codebase, if it makes sense to then having the goal of shipping the code is always a bonus.

Cheers,

Chris

Kieran Hewitson

unread,
Dec 11, 2025, 5:29:44 PM (13 days ago) Dec 11
to xp-man...@googlegroups.com, xp-man...@googlegroups.com
We have been using the same method Christoffer Gamrath described for a good number of years now on our production delivery (well, since not long after Covid hit). Very effective, especially when employing the driver navigator pattern. Every mob member should be ready to drive, with the repository cloned and up to date, and everyone pulls after a push.

We also found shared IDE environments lead to a reduction in focus, amongst everything else Christoffer described.

Google meets is what we’ve used and no complaints here - most screen sharing tools I imagine are sufficient these days.

Kieran.

Sent from my iPhone

On 11 Dec 2025, at 12:43, 'Christoffer Gamrath' via xp-manchester <xp-man...@googlegroups.com> wrote:


Reply all
Reply to author
Forward
0 new messages