Learn Go with Tests (Chris James) (Z-Library)

【One-Line Pitch】 A hands-on introduction to Go that teaches the language through test-driven development, using small, real projects to build both idiomatic Go skills and disciplined engineering habits. Best for developers who already program in another language and want to learn Go by doing, not by reading reference manuals. 【Book Arc】 - **Opening (~0%–10%)**: Establishes the core feedback loop—write a failing test, make it pass, then refactor—and applies it to the smallest possible programs: a Hello function, integer addition, and iteration. Introduces the idea of separating domain logic from side effects so code becomes testable. - **Early (~10%–30%)**: Builds up Go's type system through TDD: structs, methods, interfaces (including Go's implicit interface satisfaction), pointers and value-copy semantics, maps, and error handling as values. Moves into concurrency with goroutines, channels, `select`, `sync.WaitGroup`, and `context`, plus benchmarking and the "make it work, make it right, make it fast" ordering. - **Middle (~30%–50%)**: Applies TDD to richer problems—reflection-based walking of arbitrary data, a Roman numeral converter, trigonometry-driven SVG clock rendering, and file-system abstractions using `io/fs`, `embed`, and `html/template` for a blog renderer. - **Late (~50%+ of excerpt coverage)**: Continues expanding the blog renderer into an index page and beyond, reinforcing API design through tests and dependency injection. The excerpts do not cover the final chapters in detail. - **Ending**: Not covered by the excerpts; the guide cannot describe the book's closing material. 【Key Takeaways】 - **Refactoring means changing structure without changing behavior** (Opening): the book grounds this in the maths idea of factorisation—rewriting an expression so it fits your domain better while remaining equivalent. This framing makes refactoring a disciplined step, not a vague cleanup. - **Separate domain logic from side effects to make code testable** (Opening): pulling `fmt.Println` out of a `Hello` function so the string-producing logic can be tested in isolation is the book's first and most repeated design lesson. - **Go interfaces are satisfied implicitly** (Early): a type satisfies an interface simply by having the required methods—no `implements` declaration. This enables decoupling helpers from concrete types and is a recurring design tool throughout the book. - **Method receivers are copies** (Early): the Wallet example shows that value receivers copy the value, so mutations don't persist. Understanding this is essential before pointers and stateful types make sense. - **Errors are values** (Early): extracting a shared error variable gives a single source of truth and lets tests assert on meaning rather than exact wording—a pattern the book reuses for dictionary operations and beyond. - **Concurrency is introduced through tests, not theory** (Early): goroutines, channels, `select`, `sync.WaitGroup`, and `context` cancellation are all exercised via failing tests and benchmarks, including a race between two async operations. - **Benchmarking enforces the work/right/fast order** (Early): the `CheckWebsites` benchmark with a deliberately slow stub shows how to measure before optimizing, echoing Knuth's warning against premature optimization. - **Thin vertical slices beat big designs** (Early–Middle): the Roman numeral and clock chapters repeatedly start with the smallest useful case (1, then 10, then 1984) rather than designing the whole solution upfront. 【Reading Tips】 - **Deep-read the Opening and Early chapters.** The TDD cycle, interface semantics, and pointer/value distinctions are foundational; skimming them will make later chapters confusing. - **Type the code yourself.** This is a tutorial book; the value comes from running failing tests and watching them pass, not from reading finished solutions. - **Skim the reflection and SVG/trigonometry chapters on first pass** if you're not immediately applying them—they're valuable but narrower in everyday use. Return when you need them. - **Treat the blog renderer as a case study in API design.** Notice how each new feature starts with a test that forces a design decision, and how dependency injection and `io.Writer` keep code loosely coupled. - **Don't test third-party libraries.** The book explicitly warns against it; use approval tests and dependency injection instead. 【Coverage Limits】 The excerpts cover roughly the first half of the book in detail, with the later chapters (including the ending) only partially represented. Specific chapter titles, final projects, and concluding material are not described here.