iOS Test-Driven Development by Tutorials ( etc.)（Z-Library）

【One-Line Pitch】 A hands-on guide that teaches iOS developers how to turn requirements into tests and tests into production code, using three progressively complex real-world apps. Best for Swift developers who know the basics of iOS but have little or no experience with unit testing or TDD. 【Book Arc】 - **Opening (~0%–13%)**: Sets up tooling (Xcode 13 / Swift 5.5) and frames the core idea — TDD as the discipline of writing a failing test before any production code. Introduces the Red-Green-Refactor cycle and the three sample apps used throughout. - **Early (~13%–32%)**: Builds TDD fundamentals through the Fitness app: XCTest basics, test naming conventions, the given/when/then structure, and the `sut` (system under test) pattern. Walks through a cash-register playground to internalize the cycle. - **Middle (~32%–55%)**: Deepens the cycle with refactoring discipline — eliminating duplication, extracting well-named methods, and trusting "code smells." Expands the cash register with `addItem`, `transactionTotal`, and `acceptPayment` to show how features accumulate one small cycle at a time. - **Late (~55%–80%)**: Moves into TDD with networking via the Dog Patch app — testing RESTful calls, image downloads, and networking clients, where mocking and test expectations become essential. - **Ending (~80%–100%)**: Tackles TDD in legacy apps through MyBiz, an ERP app without test coverage. Focuses on retrofitting tests into untested code and building confidence incrementally. 【Key Takeaways】 - **TDD is a four-step loop, not a one-time activity** (Early): Red (failing test) → Green (minimum code to pass) → Refactor (clean both app and test code) → Repeat. The "repeat" step is what actually builds the system. - **Tests must be fast, repeatable, and maintained** (Early): All prior tests must pass before writing a new one; suites should run in seconds, ideally under one second total, or developers stop running them. - **Write the bare minimum to pass** (Middle): When adding a single item, setting `transactionTotal = cost` is correct — not `+=`. Resist over-engineering; the next cycle will force the generalization. - **Know what not to test** (Early): Skip generated code, compiler-catchable issues, and dependency/framework internals. Do test your own methods, custom getters/setters, and subclasses of framework types. - **TDD pays off over the long run** (Early): It costs more upfront code, but reduces maintenance cost and bug count — most valuable for projects lasting months or spanning multiple releases. - **Refactoring is where design improves** (Middle): Duplication in tests (repeated setup) and production code gets extracted into instance variables and well-named methods; comments explaining "how" are a smell. - **Networking and legacy code are testable too** (Late): Mocking, test expectations, and networking clients extend TDD to REST calls; legacy apps can adopt TDD incrementally without full coverage first. 【Reading Tips】 - **Read cover-to-cover if new to testing**; if you already write tests, jump to the networking or legacy-app sections as reference. - **Type along with the playground and starter projects** — the cash register example is deliberately small so you feel the cycle, not just read about it. - **Deep-read the refactor step**; it's the most skippable-looking and the most valuable for long-term code health. - **Don't memorize `XCTAssert` variants early** — the book defers them; focus on the cycle first. - **Treat the three apps as a progression**: Fitness for basics, Dog Patch for async/networking, MyBiz for real-world messy code. 【Coverage Limits】 The excerpts cover the introduction, TDD cycle, and early-to-middle cash register example in detail, but only summarize the networking and legacy-app sections; specific chapter-level techniques there are not fully represented.