TDD Code Kata Experiment

July 12, 2018    TDD UnitTesting Craftsmanship Presentation

What we learned from leading a TDD Code Kata lunch and learn

I’ve been wanting to try out a code kata for a long time. I’ve also been wanting to get better at Test Driven Development (TDD). I decided that the best way to make time, is to lead one of our regularly scheduled Lunch and Learns at Omnitech. I didn’t really know what I was doing, but I’m ok with failing in front of others at Omnitech and knew that our team would work together as we went through it.

I chose a Roman Numeral TDD Kata that I found with Bing on GitHub.

We hard coded our way through the cycle of failing test, passing test, refactor (remove duplication). About 30 minutes in we got stuck. We talked about “When do you keep hard coding values to make the tests pass and when do you make big steps?”. This is a question I will be thinking about for a long time.

Some retrospective after the exercise

Some things I learned:

  • TDD helps when you don’t know what to do next
  • I tend to over hard-code when doing TDD
  • It’s ok to/you should research your domain more before coding (if you can)
  • I like the TODO list where you can write down ideas and come back to them later to avoid distractions

“TDD or TDD-like development helps me think of edge cases (there’s actually a bunch of different edge cases for this problem around parsing invalid Roman numerals that I didn’t account for in my solution, thinking in terms of tests for each functional area helped flesh this out)

I think a focus on just getting the tests to pass is too narrow - when I did it, I wrote tests grouped functionally (single character, multiple additive characters, subtractive characters, invalid characters, etc) and modified my general solution to work for each class of tests as I went, instead of just the tests that I had written. This helped me avoid hard-coding for certain cases.”

“The problem with baby steps (in my opinion) is that I don’t know how I would go from multiple hard-coded subtractive edge cases (4, 9, etc) to a general solution - I don’t see a logical refactor from multiple edge cases to a general solution.”

Maybe baby steps are good as you get a sense of the problem? But once you’ve built some intuition, I think you need to think in bigger leaps to get to that general solution.

Is the TDD approach different for a domain that is known versus a new business approach you are discovering?

There is much to learn and practice to get to true TDD, but it was still worth sharing

Uncle Bob Insight

Uncle Bob talks about The Cycles of TDD. I didn’t now this before trying it out, but we were stuck in the “Deca-minute” of TDD. “As the tests get more specific, the code gets more generic.”.

"Once you are stuck, the only solution is to backtrack up through the previous tests, deleting them, until you reach a test from which you can take a different fork in the road."

I think that is what I need to do (if I can get back to trying the TDD again).

Other TDD Katas and Resources



comments powered by Disqus

Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!

Support me and download Brave!

Use Brave