Learning Test-Driven Development A Polyglot Guide to Writing Uncluttered Code (Saleem Siddiqui)（Z-Library） (1)

# Learning Test-Driven Development: A Polyglot Guide to Writing Uncluttered Code ## 【One-Line Pitch】 A hands-on, language-agnostic guide to mastering test-driven development through the same money-management problem solved in Go, JavaScript, and Python—perfect for developers who want to break out of "write code, then test" habits and build confidence in clean, test-first practices. ## 【Book Arc】 - **Opening (~0%–13%)**: Establishes why TDD matters despite decades of evidence supporting it, addresses common excuses for avoiding it, and defines the target audience—developers who can already code in at least one language but want to learn disciplined testing. - **Early (~13%–23%)**: Sets up the polyglot approach with a comparison of Go, JavaScript, and Python (typing, error handling, testing support), plus practical project structure with separate folders for each language and environment setup. - **Early (~23%–32%)**: Introduces the Red-Green-Refactor (RGR) cycle through the "Money Problem"—building a simple Dollar class with multiplication, starting with a failing test, implementing minimal code, and refactoring to remove duplication. - **Middle (~32%–42%)**: Expands the money domain to multicurrency support, introducing the Money class with currency fields, handling fractional amounts (float64 in Go), and overriding equality in Python. - **Middle (~42%–48%)**: Tackles portfolio evaluation and addition of multiple Money objects, showing how TDD guides design decisions like rest parameters in JavaScript and modularization between test and production code. - **Late (~48%–end)**: Continues through error handling, redesign opportunities, and continuous integration setup—though excerpts primarily cover the early-to-middle stages of the money problem. ## 【Key Takeaways】 - **TDD is a rediscovered practice, not a new invention** (Early): The Mercury Space Program used punch-card TDD decades ago, and Kent Beck "rediscovered" rather than invented it—yet it's still the first practice sacrificed under schedule pressure despite evidence it reduces defects and improves confidence. - **The RGR cycle is the core rhythm** (Early): Red (write failing test) → Green (minimal implementation) → Refactor (remove duplication, improve readability)—this three-phase loop is the foundation for every subsequent chapter, with transitions becoming smoother as you progress. - **Start with the simplest possible test** (Early): The first test for Dollar multiplication fails with "Dollar is not defined"—this deliberate failure validates the test harness before any production code exists, establishing the test-first mindset. - **Hardcoding is acceptable—temporarily** (Early): Getting to green by returning a hardcoded "10 USD" feels wrong but is intentional; the refactoring phase then reveals subtle duplication and logical coupling between test and code that needs addressing. - **Language differences shape TDD implementation** (Early): Go has built-in testing support, JavaScript relies on external libraries (though this book uses only the assert package), and Python includes unittest—understanding these differences helps you apply TDD across ecosystems. - **Type changes ripple through your code** (Middle): When adding division to Money in Go, changing amount from int to float64 breaks multiplication—you must convert multipliers and divisors explicitly, showing how TDD surfaces type-related design decisions. - **Equality needs explicit definition** (Middle): Python's default __eq__ compares by reference, not value—overriding it enables single-line assertions and cleaner test code, demonstrating how TDD drives better object design. - **TDD guides API design** (Middle): The Portfolio class emerges naturally from writing tests for addition—using rest parameters in JavaScript and modularizing test/production code into separate files with clear namespaces. ## 【Reading Tips】 - **Skim the Preface's language comparison table** (Early): The Go/JavaScript/Python feature comparison is useful reference material but not essential reading—return to it when you need to understand language-specific testing quirks. - **Deep-read Chapter 1's RGR cycle** (Early): This is the conceptual heart of the book; the three phases are clearly marked here but become seamless later, so mastering this chapter makes everything else easier. - **Follow one language at a time**: The book presents the same problem in all three languages—pick your primary language first, then revisit for comparison; the folder structure (go/, js/, py/) supports this approach. - **Expect type-related friction in Go**: The float64 conversion issue is a common stumbling point—pay attention to how the book resolves mismatched types, as this pattern recurs. - **Don't skip the refactoring discussions**: The "Cleaning Up" sections reveal the thinking behind removing duplication and coupling—these insights matter more than the code itself. ## 【Coverage Limits】 This guide covers the book's opening through the portfolio addition stage (~48%). The excerpts do not cover later chapters on error handling, redesign, or continuous integration setup in detail. ##