Makers — Week One Debrief — Pairing and TDD

Image credit — Photo by Caleb Woods on Unsplash

In my earlier post I described how Sourdough production could be the next best thing in coding productivity hacks.

Oh blimey, this course is whizzing past. I’m trying to reflect on the whirlwind that was week 1, while week 2 is already dissolving before my eyes.

While day 1 was consumed with introductions and general settling in, the rest of the week was a chaotic charge to the weekend.

The focus of week 1 was Test Driven Development (TDD) and pairing.

Pair Programming

Pairing as it sounds, involves working side by side with another person. You may have defined roles such as driver or navigator that you rotate, but my experience is that we all tend to default to just working side by side and checking in with each other regularly to maintain a forward momentum.

For a generally antisocial type I find it pretty difficult to pair for an entire afternoon. I never spend that much time so intensely focussed in a shared space.

While it exhausts me and I yearn desperately for some alone time, I do see the benefits. It’s a really effective way to spread learning (and probably viral infections). One person learns a snazzy new keyboard shortcut to comment-out blocks of code in an instant and within days (we rotate partners daily), it has rippled throughout the entire cohort. We are all writing comments at the speed of light and sharing new tips that make us look like RSpec ninjas.

Test Driven Development

Test Driven Development (or TDD) by comparison is an absolute joy. I thought it was going to be pretty tedious but I do really love it.

It’s like David Allen’s Getting Things Done (GTD) for coders. Just as GTD allows you to take one mega project and break it down to manageable chunks or ‘next steps’. So TDD provides a mechanism to avoid severe design panic and creates a route for programmatic design to emerge through a series of next steps.

It’s a totally cool productivity hack

If on day zero, I had been tasked with the challenge of building an air traffic control system I would have collapsed into a fairly severe, minor-panic. Fortunately that task was left for the weekend of week 1. By then I was practically a leading expert in TDD and so had this challenge totally covered!

The gist of TDD is that you write failing tests and then one by one you write code to make them pass. It sounds a bit arse-about-face; who tests something that doesn’t even exist yet?

Air Traffic Control and TDD

You start the process trying to understand the user stories or required features. In this case my customer is an Air Traffic Controller who wants to be able to land planes safely and efficiently. So in discussion with the ATC I might break that down into features like:

1. Need to be able to instruct planes to land at airports
2. Need to be able to instruct planes to take-off from airports
3. Need to restrict landing and take-off is weather is stormy
4. Can’t take-off from airport unless plane is already in the airport
5. and so on.……

Now I need to create my first failing feature test. You might do this in IRB and the code for user test 1 would be something like create airport, create plane, land plane at airport

In Ruby it would look something like:

Gatwick = Airport.new
Boing747 = Plane.new
When the feature is fixed, this bit isn’t going to raise an error — ->
Gatwick.land(Boing747)

Now given that this is just a test and I haven’t written any code for my air traffic control system, it is obviously going to fail. It’s going to say hold on a minute , what the heck is an Airport and a Plane and I’ve never even heard of this land instruction — no can do!

We need to break these errors down into individual unit tests where we recreate each error revealed by the feature tests.

In this case the first error is What the heck is an Airport???. So my first unit test would be expect (Airport.new).to not_raise an Error — this will also fail as I still haven’t written any code.

This is when the joy of programming starts to unfold slowly. Both errors tell me that my programming language has no clue about Airports, so my first bit of code is to write an Airport class. In Ruby that is just:

class Airport
end

I run my tests again. The unit test turns green and passes — I feel like a coding rock star!!

The feature test still fails but the error has moved on a bit. Now Ruby is wondering What the heck is this Plane you speak of???

I’m on a roll now, my next step is to write a unit test that mirrors the error of my feature test. How about expect (Plane.new).to not_raise an Error ?

It fails. But in my new world of TDD, failure is a success its the desired outcome.

Next step — write the code to make it pass.

class Plane
end

This my friends is too easy…..

I run the test again, I now have two passing unit tests but my feature tests is still red (or failing).

• Next step? Recreate the error in a unit test
• Next step? Write the code to pass the test
• Next step? Run test repeat until the feature is passing.
• Next step? Move to next feature and repeat.

Through the power of a failing test you can pretty much move from scratch to a fairly rudimentary air traffic control system without ever really concerning ourselves with the bigger picture — with TDD the programming process just flows.

Who wouldn’t love a process that rewards failure?

Just as an aside, I wouldn’t recommend trialling my air traffic control system until I’ve done a bit of refactoring — perhaps in week 12….

My next post deals with the unrelenting pace of coding bootcamps and I share my tips on personality traits that may help…

Originally published at whatapalaver.co.uk on July 19, 2018.