I think this comment, at the end of the readme, makes too strong a claim: "Write a failing test and see it fail so we know we have written a relevant test for our requirements..." While a test that passes at this point is clearly not a valid test, relevance cannot be assumed from its failure. Tests are not immune from simple coding errors like using the wrong comparison operator, and beyond that, it is possible that the programmer has misunderstood precisely what it means for the intended purpose of the code to be satisfied. I find that a few percent of my tests and assertions are actually incorrect as first written, for both of the above reasons.<p>If you are thinking that I am misunderstanding the purpose of unit tests in TDD, that it is only to check that you have written the code that you intended to write, then that would raise the question of how you address the issue of fitness for purpose - these are two distinct issues, even though the goal is for the former to match the latter.<p>Also, while a test may provide an easy to understand description of the failure, there is no guarantee that all possible failures are so described.<p>Teaching testing as a fundamental part of programming is important, and I like this approach, but I think this particular claim goes a bit too far.
The README is much more useful to following the project, it's well written and worth a read.<p><a href="https://github.com/quii/learn-go-with-tests/blob/master/hello-world/readme.md" rel="nofollow">https://github.com/quii/learn-go-with-tests/blob/master/hell...</a>
A common problem I'm having with coding tutorials is the tendency to copy paste example code and gain only a superficial understanding. My version "works" but a month later I won't be able to recreate it from scratch.<p>Your test-driven approach lends itself to hands-on exercises where you introduce the pre-written test cases, explain the new concepts on generic examples, and the person completing the tutorial needs to write the code that gets the test case to pass (or maybe expand a partial solution from you).<p>Once you struggled with the compiler errors, the trial and failure, the syntax, etc. and passed the tests you will gain operational knowledge that will last a lifetime.<p>Also, a chapter zero could be made available for the absolute beginners, detailing how to assemble a free Go environment, for example VS Code + go plugin + golang package + Git SCM + delve debugger. That should get most people running in 10 minutes with a very rich and productive environment.
Readers may also be interested in the Go koans <a href="https://github.com/cdarwin/go-koans" rel="nofollow">https://github.com/cdarwin/go-koans</a><p>Similar approach focusing on writing snippets of code to make tests pass instead of writing the tests themselves.
Skimming this quickly I was surprised that constants Spanish and French were accessible in the test files. Is this a test only scope thing or just how go works?<p>Edit: it’s how to works, specifically with packages. Found this:
<a href="https://medium.com/golangspec/scopes-in-go-a6042bb4298c" rel="nofollow">https://medium.com/golangspec/scopes-in-go-a6042bb4298c</a>
Really well done so far.<p>Hopefully some of Go's distinguishing features will make it into the tutorial. Namely channels, custom types, goroutines, and interfaces.