Buttoning Up Code: a valiant team uses TDD, pairing, and XP values to defeat a bug


This is the story of a bug.

This bug was annoying and caused the coders a great deal of heartache and misery.

The coders were tempted to give up on solving the bug.

But they persevered, and the bug was fixed.

This is also the story of Makers Academy, encapsulated in this one small story about a bug.

On Monday 29 May 2017, my pair partner and I submitted a pull request for the front end we had built and styled using Ruby on Rails 5. We were quite proud of our design, and rightly so. It was a clean, elegant user interface, modelled shamelessly on Facebook (our whole-team project was to build “Acebook”).

Our coach asked for some changes, one of which being to fix a test that had mysteriously begun to fail (first lesson learned: run your tests again before submitting a PR), the second to restyle a button class according to Rails syntax.

The first failing test was relatively easy to fix: a stylesheet had been required twice. Turns out you don’t need to explicitly require your stylesheet as it will be automatically required as long as it’s located correctly.

Which led to the second error: ‘unable to find button “New Post”’.

This error would drive us round the bend.

We could see quite clearly on the page that there was a button; we could inspect it with the chrome devtools and see its lovely button classiness.

And yet Capybara couldn’t find it.

I Zoomed one of my teammates, and when he couldn’t find the error either, I retired in defeat for the night. When we resumed the next morning, I showed the error to my full team of four and no one could figure it out.

So we called in the big guns: our coach.

We then spent a good half an hour exploring differences between Rails 4 and 5 syntaxes (‘form_to’ vs. ‘form_with’ anyone?), changed a lot of things around, and eventually reset the test and code to a point at which it was working. We couldn’t figure it out.

Eventually our coach said, “Sometimes you just have to say ‘that happened’.” That sure did happen. But there was one thing I couldn’t understand: why the test passed when it said ‘click_link” when the code was clearly a button, yet failed when the code said ‘click_button’.

Then our coach got the light in his eyes that said, “I now know the answer, and I am going to leave it to you guys to figure it out.”

Needless to say, I was annoyed.

​I’d been plugging away at this error for a good three hours now, with several different teammates and lots of attempted solutions, and had gotten nowhere. I was at the frustrating stage where my code worked (I thought — I could clearly see the front end doing exactly what I wanted the test to do) but I didn’t how I had broken the test, or why it was working with the reset code.

At this point part of me still wanted to implement one of the two suboptimal solutions:

  1. Commit the test that passed mysteriously and hope no one asked us to explain it
  2. Reset the code back to its ugly, plain link/unstyled state with a comprehensibly passing test.

It was also lunchtime, which may have had something to do with my frustration.

I switched pairs to get fresh input and we plugged away at the problem and then all of the sudden it came to us in a flash — in fact, the bit of Rails magic was a link, not a button, which is why ‘click_link’ worked, even though this link had managed to get attached to a button class.


Great, so all we needed to do was to change ‘link_to’ to ‘button_to’ and be on our merry way. Simple.

Have you ever tried editing code from one unfamiliar syntax to another unfamiliar syntax while it’s lunchtime and your brain is fried from a morning of debugging?

We reconvened after lunch (in my case, a nap) and in twenty minutes had sorted out the syntax, the tests passed, and the browser looked fantastic.

The End.

The evil bug was defeated because:

  1. Curiosity and a desire to learn drove the team to find the best solution
  2. Teammates kept pushing each other forward when someone was discouraged
  3. The team shipped outstanding code, which communicated its intent clearly to the dev who will work on it tomorrow, and which can serve as a template for future code. No replication of errors on their watch!
  4. The team also shipped simple, well-refactored code: 3 lines of ‘link_to’ code became one line of ‘button_to’ which also looked better on the UI
  5. The team respected the TDD process: even when it was a giant pain in the neck to have a mysteriously failing test, we still ended up with much better code because of it
  6. The team pair programmed really effectively to solve this problem, rotating the people working on the bug so there was a good supply of fresh input mixed with the knowledge of one of the devs who wrote the code

The whole Makers Academy experience is summed up in this bug experience: pairing, TDD, XP values, and rigorous code review. I’ve never been so proud to be a MA student as I was today.

With thanks to teammates Jon, Miles and Sandy, to the rest of the remote April 2017 cohort, and to the MA staff.

Read about the second half of Rails week: Paulamorphism: tales from Rails

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s