Crush Your Coding Challenges With REAL Test-Driven Development

Most coding challenges exercise more your coding/syntax and problem-solving skills and less your analytical and anticipation skills, not to mention your ability to do Test-Driven Development as a discipline.

Let's see what we can do, with an example of how I'm going about Ruby challenges on the Exercism coding challenge platform.

On all the coding challenge platforms that I know, tests are pre-written. In Exercism you can see and even change them. On other platforms, they are even hidden or you get to see sample inputs with expected outputs. In short, tests are already there, you satisfy them with your knowledge of coding, syntax, and algorithms.

On Exercism, some mentors will also look at the design aspect of your code. For Ruby, most of the time, they will insist on an object-oriented type of design paradigm (I know, I was a mentor there as well :).

This is all great, but what if you want to step up a bit and add some spice to these challenges? For example, by doing real TDD as described in Kent Beck's books Test-Driven Development By Example or Extreme Programming. You'd be working in iterations of a cycle:

1. Red 🔴
2. Green 🟢
3. Refactor 🛠

This is not possible with the Exercism setup, since the tests are pre-written. Exercism argues that this is indeed Test-Driven Development. And in some way it is. At some resource-heavy companies, you might really have the setup that you get some tests pre-written from a team of testers who create them from a requirements specification. Or from QA people, who'd do the same but less on a unit test level and more on an end-2-end level.

However, this setup is highly uncommon. Nowadays, it's expected from developers that they write the code and the tests. Or sometimes even better, a test, and then some code to satisfy the test ;)

Test-driven development makes working with your code a joy and I try to hone this skill whenever possible, so once I need to solve a problem on the spot or on the job, I'm getting into the cycle right away.

My favorite process to solve an Exercism challenge (or any other coding challenge for that matter, if tests are available):

1. [ ] Create a tiny "design checklist" (what needs to be done?)
2. [ ] Check what Exercism expects in terms of structure (e.g. a class FootballField with a method goalKeeper(inputBalls))
3. [ ] Start coding with the TDD cycle:

➡️ Write a failing test 🔴

➡️ Satisfy the test with the most simple solution 🟢

➡️ Refactor (remove duplication and keep an eye on maintainability) 🛠

↩️ Repeat 🧑‍💻

4. [ ] Try to figure out the edge cases and happy paths on my own

5. [ ] When I think the exercise is finished: See if Exercism covers even more edge cases and run the Exercism minitest tests to see whether I've covered everything.

For this purpose I created a tiny template for my Exercism Ruby track challenges in RSpec:

exercism-exercises/rspec_template_spec.rb at main · RichStone/exercism-exercises

Contribute to RichStone/exercism-exercises development by creating an account on GitHub.

GitHubRichStone

It's RSpec because this is what I'm using at work for more than a year now. But once you see the concept it's even simpler to set it up with minitest, right? No need to install RSpec in this case.

More about TDD in Exercism, the exact template setup, and how it all works together in this step by step video: