TDD and the Golang track

[matthewmorgan]

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.

[github-actions]

Hello. Thanks for opening an issue on Exercism 🙂

At Exercism we use our Community Forum, not GitHub issues, as the primary place for discussion. That allows maintainers and contributors from across Exercism's ecosystem to discuss your problems/ideas/suggestions without them having to subscribe to hundreds of repositories.

This issue will be automatically closed. Please use this link to copy your GitHub Issue into a new topic on the forum, where we look forward to chatting with you!

If you're interested in learning more about this auto-responder, please read this blog post.