TDD and the Golang track

Hey folks,

A friendly question here more than an issue. As someone who used Exercism a lot in the past, I’ve found the Golang track a bit tricky to get traction on, mostly because it seems pretty difficult to build the data structures and the APIs incrementally, testing as you build. Maybe that’s just me, but the primary blocker seems to be that you often need to write fairly complete code before you can get meaningful feedback from the tests.

It seems like there’s been a conscious decision on the part of the maintainers to prefer generated tests, and I see a lot of tests that require fairly complete APIs. This is fine if you want to build a complete-ish solution, test it, then iterate on your solution, but it makes it difficult to build up your models and APIs incrementally, enabling relevant tests as you go (more TDD in approach.)

Any history on why that decision was taken? Is this now the standard practice on Exercism more generally, or is this a cultural artifact of the Go track?

Thanks, appreciate your time.

1 Like

Hi @matthewmorgan :wave:

All the Practice Exercises (so the ones that aren’t specifically designed to teach you the language) come from the central repository of Problem Specifications, which specifies the tests. So generally speaking I’d expect the tests to be the same on Go exercises as on other tracks.

In terms of Exercism in general, it’s intended for things to be TDD, but it does come down to the exercise as to how possible and/or well designed that is.

The Learning Exercises should be very granular though.

Do you maybe have an example or two of where you feel Go is different from the same exercise on other tracks you’ve worked on before?

Hi @iHiD ,

Thanks for your reply.

One example might be linked-list. Using the JS track for comparison, the first test requires you to implement new, push, pop. But in Golang, you also have to implement the traversal methods-- in addition to being more methods, it’s really another concept, so the scope of the first test isn’t the same across tracks.

Another trivial example is protein-translation, where to pass the first test in JS, you implement a zero-value case of the codon mapper. In Golang, you need to implement all the codons, because the first test case checks a list of codons. Of course you could go and comment out part of the codon list, but the required intervention isn’t always that obvious. Part of this is, I think, because the tests loop over many cases, calling helpers to check various bits, adding additional layers of indirection to the tests.

Anyway, I’m just wondering, mostly for my own curiosity, if the differences are intentional. Probably this is just a mental block on my part!


@andradefr8 @junedev (or @ErikSchierboom) Any thoughts on this? :)

Perhaps you intended to tag @andrerfcsantos?

I did. Thank you and sorry!

(cc @andrerfcsantos)

@matthewmorgan I started another forum thread a few weeks ago because I found the order of the tests in problem specifications by design is not respecting TDD as a process. That may be an additional source of TDD issues.

1 Like