When following along online: after the first couple of chapters, you basically get "Write tests.." or "Refactor" headings. It's very hard to tell where you are on the page or get back to a specific section (especially in the bigger chapters) because it all looks the same. (screenshot included).

I think this is due to how GitBook uses Markdown to determine chapters, but would you be open to the idea of changing the Level 3 headings to match more of what's in the content, and let the bulk of Write the test/Refactor/etc.. change to Level 4?

I know it's a lot of work, and I definitely don't mind contributing to help out with that.

Thanks for this awesome book!
I'm running Windows 10 and it took me a while to figure out that (at least using PowerShell) one has to use go test -bench="." instead of just go test -bench=. to run the benchmarks.
I think it would be cool to include a note for Windows users stating this slight difference (hope I didn't just overlook it). 😇

I am still confused with strings, bytes, runes and characters in Go after reading Strings, bytes, runes and characters in Go. Could you consider add some chapters about them?

And the requirement could be "Replace all spaces in a String with ‘%20’".

The chapter of structs does not mention new, to create structs.This is not much of problem, but ...
Then comes the chapter on HTTP server, where you do something like this:

    server := &PlayerServer{}

The unattentive reader just goes by (me reading on the train ...), the aware reader looks at the & and thinks:

mmm ... strange. I know this from C. Why do we deference this here?

Now, I read somewhere along in your AWESOME book (I'm already using some of the techniques in Python) that we don't want to pass values by copying them into the functions, so it makes sense to me. But I am thinking it's worth an explicit explanation on this syntax.

If you accept a PR I don't mind trying to explain it.

The test condition len(store.winCalls) != 1 will always return False because of the previous test also recording a win.

The store should ideally be reset for every test to avoid making the tests dependent on each other.

Any interest in editing/maintaining this is something like GitBook?

The sub-directories of concurrency are "v0", "v1" and "v2" which starting with "v0". But in the previous chapters, the sub-directories start with "v1".

Both @lnryan and @shinyhappydan have mentioned how it is not clear where the files should go for hello-world.

e.g $GOPATH/src/github.com/{user}/hello

Let's just add some text to explain that

Should the code be updated to correct the lint issues from goreport?

Damian.

ideas...

• Start with a number of functions that take the same collection of primitives
• Then show how we can refactor these things into a struct
• Add some methods?
• Now that the reader knows about structs we could maybe bring in table based tests too

Avoid pointer stuff for now.

The next chapter can do pointers to show how we can modify state

A typing error in the chapter of mocking-wip
func Countdown(out io.Writer) { for i := 5; i > 0; i-- { fmt.Fprintln(out, i) } fmt.Fprint(w, "Go!") }
fmt.Fprint(w, "Go!") ==>fmt.Fprint(out, "Go!")

Btw,this approach to learn go is awesome,very helpful, look forward your updating.

In the website's Context section, the text states:

We removed the reference to ctx from the SpyStore's fields because it's no longer interesting to us.

I searched but I couldn't find the section where ctx was added to SpyStore.

Also, the subsequent test still checks this field:

    if store.ctx != request.Context() {
        t.Errorf("store was not passed through a context %v", store.ctx)
    }

These lines seem to have been removed from the code file, but are still present in the markdown file.

I think the checking of num is unnecessary in chapter concurrency.

want := len(websites)
    got := len(actualResults)
    if want != got {
        t.Fatalf("Wanted %v, got %v", want, got)
    }

Because reflect.DeepEqual has done it for ourselves. I think it's good for the codes just like the v0-CheckWebsites_test.go:

want := map[string]bool{
		"http://google.com":          true,
		"http://blog.gypsydave5.com": true,
		"waat://furhurterwe.geds":    false,
	}

got := CheckWebsites(mockWebsiteChecker, websites)

if !reflect.DeepEqual(want, got) {
    t.Fatalf("Wanted %v, got %v", want, got)
}

We show how to write examples but not how to view them

Hi
How could I add a test case for func main so I get 100% test coverage?
I am using this plugin which shows errors and test coverage at status bar every time I save
https://marketplace.visualstudio.com/items?itemName=joaoacdias.golang-tdd

Hi,
I don't know if this is by purpose but the PDF is missing the awesome illustration which the ePub got as a Cover.

Also maybe a tag with the version of release would be a nice feature on a page.

Chéers!

I'm not quite sure if that's covered in other chapters, but I'm struggling with testing my database/sql stuff.
The mocking and dependency injection chapters were useful, but I'm still lost.

Let's say, that I've got something like that:

type Connection struct {
	*sql.DB
}

func NewDatabaseConnection(host, database, user, password string) (*Connection, error) {
	u := &url.URL{
		Scheme: "sqlserver",
		User:   url.UserPassword(user, password),
		Host:   fmt.Sprintf("%s:%d", host, 1433),
	}

	db, err := sql.Open("mssql", u.String())
	if err != nil {
		log.Fatal("Error opening database connection:", err)
	}

	return &Connection{db}, nil
}

How, if it's even needed, should I test that? Or something like a GetUser function.
A chapter about that would be awesome =) Maybe, since we've already got a "HTTP server" and "JSON" chapter, a little extension to those?

Chapter with examples of how to test code that for example does:
os.Open('file')
and all other interactions with FS.

I'm noticing terminology that your average Junior developer and even many that have come up in a relatively stable, siloed domain would likely be spotty on. Is it worth a glossary on these or links to definitions? I realize they're not go specific...

If it's wanted, I can help with the leg-work

Examples:

• DSL
• Opinionated
• Domain

Hi,
it would be great if the version of the release is also included in the output file (e.g. PDF), so it is easy to determine which version is currently viewed.

Thanks

I've been writing code following the text in the time chapter and around L772 things seem to go off the rails a bit in terms of what the text mentions and the state of passing code. Around this paragraph:

This should just be an exercise in copying the tests from the CLI_test into a new set but with less dependencies to set up; so we wont show all the code here (you can always check the full source here) but here is an example of one of the moved tests for reference.

That's not to say that it's incomprehensible or that the diligent reader can't work it out but it does feel markedly different from the rest of the book up until this point. I realize this is vague - I will attempt to fill in further details if I find the time, but I wanted to flag it before I forget. I think anyone who writes the code themselves while reading will understand what I mean.

The main issue I'm finding is that there is a considerable gap and amount of work to get the tests back to green and it seems like the text chugs through it. It seems like there are too many test changes along with creating new things and moving things while in the red state.

Go's declarative nature can mean a lot of boilerplate involved in preparing a test. One option is to use the TestMain function to set global state used by many tests:

var thing Thing
func TestMain(t *testing.M){
  thing = setup()
}

Avoid this pattern whenever possible. Global state bugs lead to fear, anger and the dark side.

Another approach is to copy and paste code around many similar top level tests. You have certainty that no variable state is shared between tests, with the drawback of extra maintenance costs:

func TestThingDoesXGivenA(t *testing.T) { thing := setup();  ... }
func TestThingDoesXGivenB(t *testing.T) { thing := setup();  ... }
func TestThingDoesYGivenC(t *testing.T) { thing := setup();  ... }

Table driven tests use a loop to avoid duplicating boilerplate. They can be easier to comprehend and easier to maintain, because there's no duplicates of the lines that assert the behavior:

func TestThing(t *testing.T) {
	type testcase struct {
		input, expected string
	}

	testcases := []testcase{
		testcase{
			input:    "a",
			expected: "x",
		},
		testcase{
			input:    "b",
			expected: "x",
		},
		testcase{
			input:    "c",
			expected: "z",
		},
	}
	for _, tc := range testcases {
		t.Run(fmt.Sprintf("%s given %s", tc.expected, tc.input), func(t *testing.T) {
			thing := setup() // or put outside the loop if you're not concerned about shared state
			actual := thing(tc.input)
			if actual != tc.expected {
				t.Fatalf("expected %q got %q", tc.expected, actual)
			}
		})
	}

}

func setup() func(string) string {
	return func(input string) string {
		switch input {
		case "a", "b":
			return "x"
		case "c":
			return "y"
		default:
			return ""
		}
	}
}

The t.Run method allows you to label tests, like a describe block in other languages' tests. go test -v -run 'TestThing/z_given_c' lets you run a specific subtest, which can be nice if you don't want to see log output from other tests or subtests.

I have made dozens of mistakes when changing the snippets of Go code in the readme files

Whilst the build.sh will check all of the code examples, it cant check the contents of the markdown files

So it's all manual checking and i am rubbish at that.

There has to be a way to automate it

Did an in retrospect bad refactor but didn't get too upset about it. By working iteratively with tests it's not such a big deal.

An alternative view would be that in this case the refactoring wasn't pushed far enough. Example:

package main

import "reflect"

type ReportString func(input string)

type getByIndex func(index int) reflect.Value

func Walk(x interface{}, fn ReportString) {
	val := getValue(x)

	switch val.Kind() {
	case reflect.String:
		fn(val.String())
	case reflect.Struct:
		walkByIndex(val.NumField(), val.Field, fn)
	case reflect.Slice, reflect.Array:
		walkByIndex(val.Len(), val.Index, fn)
	case reflect.Map:
		walkByKey(val, fn)
	}
}

func getValue(x interface{}) reflect.Value {
	val := reflect.ValueOf(x)

	if val.Kind() == reflect.Ptr {
		return val.Elem()
	}

	return val
}

func walkByIndex(numberOfValues int, get getByIndex, fn ReportString) {
	for i := 0; i < numberOfValues; i++ {
		Walk(get(i).Interface(), fn)
	}
}

func walkByKey(val reflect.Value, fn ReportString) {
	for _, key := range val.MapKeys() {
		Walk(val.MapIndex(key).Interface(), fn)
	}
}

or possibly even

package main

import "reflect"

type ReportString func(input string)

type fetchValue func(index int) reflect.Value
type initWalk func() (length int, fetch func(index int) reflect.Value)

func Walk(x interface{}, fn ReportString) {
	val := getValue(x)

	switch val.Kind() {
	case reflect.String:
		fn(val.String())
	case reflect.Struct:
		walkAll(structInit(val), fn)
	case reflect.Slice, reflect.Array:
		walkAll(sliceInit(val), fn)
	case reflect.Map:
		walkAll(mapInit(val), fn)
	}
}

func getValue(x interface{}) reflect.Value {
	val := reflect.ValueOf(x)

	if val.Kind() == reflect.Ptr {
		return val.Elem()
	}

	return val
}

func walkAll(init initWalk, fn ReportString) {
	numberOfValues, fetch := init()
	for i := 0; i < numberOfValues; i++ {
		Walk(fetch(i).Interface(), fn)
	}
}

func structInit(container reflect.Value) initWalk {
	return func() (int, func(int) reflect.Value) {
		return container.NumField(), container.Field
	}
}

func sliceInit(container reflect.Value) initWalk {
	return func() (int, func(int) reflect.Value) {
		return container.Len(), container.Index
	}
}

func mapInit(container reflect.Value) initWalk {
	keys := container.MapKeys()
	fetch := func(i int) reflect.Value {
		return container.MapIndex(keys[i])
	}

	return func() (int, func(int) reflect.Value) {
		return len(keys), fetch
	}
}

Aside: The order of the map keys doesn't seem to be guaranteed - every once in a while:

$ go test
--- FAIL: TestWalk (0.00s)
    --- FAIL: TestWalk/Maps (0.00s)
    	reflection_test.go:98: got [Boz Bar], want [Bar Boz]
FAIL
exit status 1
FAIL	_/Users/wheatley/sbox/golang/test-go/12/src	0.006s
$ go version
go version go1.10.3 darwin/amd64
$

One of the best approaches to teach Golang I've seem

Keep going!

After Bitcoin implement String(), %v -- &wallet.balance only return the Sprintfing value
fmt.Printf("address of balance in TestWallet: %v \n", &wallet.balance)
// output: 
address of balance in TestWallet: 10 BTC 

• How to print its address ?

In IO and sorting chapter, create tmp file helper function should close before remove

`func createTempFile(t *testing.T, initialData string) (io.ReadWriteSeeker, func()) {
t.Helper()

tmpfile, err := ioutil.TempFile("", "db")

if err != nil {
    t.Fatalf("could not create temp file %v", err)
}

tmpfile.Write([]byte(initialData))

removeFile := func() {
    **tmpFile.Close()**
    os.Remove(tmpfile.Name())
}

return tmpfile, removeFile

}`

https://github.com/quii/learn-go-with-tests/blob/0e94809c8a308e995d3f5e80ae43587880991700/io/v3/FileSystemStore_test.go#L22

Ideally it would be good if everyone didn't have to suffer from reading my terrible grammar and spelling and that it was integrated into the travis build.

Whatever it is, it will need to recognise markdown because it'll need to ignore code and code blocks

Hello, I'm a gopher, I founded the Go Chinese community https://studygolang.com in 2013. In order to better promote the go language, the introduction of foreign excellent information to China, in November 2017, I organized the GCTT (Go Chinese Translation Team). 2 months ago, I saw your articles about TDD, and GCTT start translating, and later discovered https://github.com/quii/learn-go-with-tests this project, thanks for providing such a good project, GCTT wants to translate it into Chinese, I wonder if we can do that? Looking forward to your reply. Thank you!

Ideas

• Write a test where we want a method to change the value of a thing, but show that by not using pointers it does not change it.
• Explain how everything in Go is pass by value (i.e everything is copied), so if we wish to change the value of something via a function/method then we will need to pass a copy of a pointer instead. This pointer can then be used to change a value as we intend

Need to cover

• Talk about design choices, if a thing is "big" then we may want to pass a pointer to it, even if we dont want to modify it. Can an example be made here via benchmarking?

Hey!

So I'm going to work up a section on concurrency.

Dave!

@quii Named result parameters are recommended only in certain context. The last refactor in Hello, World gives an impression to use named results parameters in general to make the documentation clear. Should we update it to not use named result param since its pretty clear from the function name itself what it is going to return?
If we agree on this, I can raise the PR for same.

Ref: https://github.com/golang/go/wiki/CodeReviewComments#named-result-parameters

It's not entirely clear here, whether it takes 139 nanoseconds on average or in entirety, it could be deduced from ns/op but would not necessarily be obvious to someone new, nor that the 10000000 is the number of executions as opposed to some other stat.

Might be worth some further explanation?

For kicks, I tried the following

func BenchmarkRepeatFlat(b *testing.B) {
	for i := 0; i < b.N; i++ {
		Repeat("a", 10)
	}
}

func BenchmarkRepeatIncr(b *testing.B) {
	for i := 1; i <= b.N; i++ {
		Repeat("a", i)
	}
}

and got

not unsurprising, but ... a lesson in how not to be clever

It's common to test a piece of code that relies on some other type. You can instantiate a "real" version of the dependency and use it in the tests, but that may have costs - it may run slowly, return something different every time, or be complicated to configure. I prefer to use an interface to declare what the dependency does, so I can use a "mock" version of that type in the tests.

Feel free to copy and/or modify http://therealplato.com/posts/soberoctober11/#quick-pattern-dependency-injection . May be worth providing examples both with and without github.com/stretchr/testify/mock

Made a start with arrays, need to continue into slices. Transition can be motivated by needing varying length arrays, refactor to slices

In my opinion, I think that the Sleeper implementation test would be very helpful here. However, I am not sure how this would be done in a nice way.

I would love to help with this if I can get just a little guidance on how to handle this in an idiomatic Go way.

Hi, not sure if this qualifies as an issue. But, I was hoping to see discussion about some things:

• The chapter defines a Shape interface with the Area() method. If you add another method to the Shape interface, all shapes (ie. rectangle, circle, triangle) have to implement the new method (Perimeter).
• So it makes sense why there are a lot of 1 method interfaces.

type Shape interface {
    Area() float64
    Perimeter() float64
}

When you go and implement Perimeter for all the shapes, you realize you can't get the perimeter of a triangle with base and height.

I suggest changing the name Triangle to RightTriangle, because the perimeter is defined. Then the discussion can continue.

We've got a few chapters in progress that uses maps but have not actually explained them!

Could be a potentially interesting chapter as they can be used in a number of ways

• Key/Value store (obviously)
• Sets

Could cover that they are not safe for concurrent use

There are two fmt.Printlns in pointers-and-errors.md:

• fmt.Println("address of balance in test is %v \n", &wallet.balance)
• fmt.Println("address of balance in Deposit is %v \n", &w.balance)

will raise Println call has possible formatting directive %v.

Solution is to update to fmt.Printf: fmt.Printf("address of blance in test is %v \n", &wallet.balance)

Hi,
I am lost in how to implement postgres with test, I have read and write "Build an application" multi times and want to write a postgresql store, but I don't know how to easily create initialization data and clean them，should I use insert to create init data then clean them after test? I want to know if there is a more elegant way to test the real database.

Thanks lot!

The initial sum_test.go example in the document results in the following error when implemented as shown:

sum_test.go:1:1: expected 'package', found 'func'

The example should include:

package main

import "testing"

to match the example at https://github.com/quii/learn-go-with-tests/blob/master/arrays/v1/sum_test.go.

After you introduce the need for a tape struct (BTW, you went against your own dicta/modus operandi by writing the implementation first and then the test, even though the heading after "Another problem" is "Write the test first"), my test does not fail with the got 'abc45' want 'abc' problem. Instead, the build fails with:

./FileSystemStore.go:17:18: cannot convert database (type io.ReadWriteSeeker) to type tape

That makes sense to me because you only implemented the Write method.

Going on with the next section and replacing the io.Writer by *os.File, causes the test to fail again with another message (in addition to the one above):

./tape_test.go:12:16: cannot use file (type io.ReadWriteSeeker) as type *os.File in field value: need type assertion

You state "You should be able to fix these problems yourself by now but if you get stuck just check the source code." The problem if one gets stuck is that there's no snapshot of the code at this point (by my reckoning it would have to be something like V6.5). Anyway, I'll give it a try and if needed i'll update this issue further.

While running go test with the ExampleAdd() function, I observed that if we remove the comment(Output: 6), the test will not execute this function. I checked the go documents and found out
here - https://golang.org/pkg/testing/#hdr-Examples

Example functions without output comments are compiled but not executed

May be we can add this as a note in Integers Section ?

A few people have asked how to test these.

In the hello_world examples, assertCorrectMessage should accept a *testing.T argument. The way it is currently written, the subtests never fail from an assertion, just TestHello.

v5 should look something like this:

func TestHello(t *testing.T) {

	assertCorrectMessage := func(t *testing.T, got, want string) {
		t.Helper()
		if got != want {
			t.Errorf("got '%s' want '%s'", got, want)
		}
	}

	t.Run("saying hello to people", func(t *testing.T) {
		got := Hello("Chris")
		want := "Hello, Chris"
		assertCorrectMessage(t, got, want)
	})

	t.Run("empty string defaults to 'world'", func(t *testing.T) {
		got := Hello("")
		want := "Hello, World"
		assertCorrectMessage(t, got, want)
	})

}

This will cause the output of go test to be:

--- FAIL: TestHello (0.00s)
    --- FAIL: TestHello/empty_string_defaults_to_'world' (0.00s)
        hello_test.go:23: got 'Hello, ' want 'Hello, World'
FAIL
exit status 1
FAIL    github.com/quii/learn-go-with-tests/hello-world/v5      0.006s

That makes it easier to track down which subtest failed.

Chris I came across this article is there value incorporating anything from this?

Damian.

I created a folder and started working through the code examples.

I got to here https://github.com/quii/learn-go-with-tests/tree/master/integers#examples

And realised that godoc wont work for this example as the code is outside of the GOPATH.

Is there a recommendation on how you should setup your project / directory structure / location that will work with the tutorial?

Thanks,
Damian.

On page 67 the Refactor section needs further information because with those changes then test fails in subsequent sections

./dictionary.go:3:8: imported and not used: "errors"
./dictionary.go:16:5: invalid case ErrNotFound in switch on err (mismatched types string and error)
./dictionary.go:19:9: cannot use ErrWordExists (type string) as type error in return argument:
	string does not implement error (missing Error method)
./dictionary.go:34:16: cannot use ErrNotFound (type string) as type error in return argument:
	string does not implement error (missing Error method)
./dictionary_test.go:34:20: cannot use ErrWordExists (type string) as type error in argument to assertError:
	string does not implement error (missing Error method)
./dictionary_test.go:99:20: cannot use ErrNotFound (type string) as type error in argument to assertError:
	string does not implement error (missing Error method)

This project seems (?) to be similar to cdarwin/go-koans. Any thoughts on taking on that project or using it to inspire this one?

Text in the book says to add the ExampleAdd() function to adder_test.go, however it won't compile because the "fmt" package hasn't been imported into adder_test.go

Easy and simple to fix, perhaps instead it could be an opportunity to suggest to the reader to have a go at fixing the problem before telling them what the fix is.