# Chapter 9: The Software is Still for the Customer
**"Iteration and Testing"**
## Overview
This chapter emphasizes that no amount of well-designed code matters if the software doesn't actually work for the customer. It introduces the concepts of **Iterative Development** and **Testing** as critical tools to prove your system's value. The chapter walks through finalizing the `Unit` class for Gary's Game System Framework (GSF) and introduces **Programming by Contract** and **Defensive Programming**.
---
## 1. Two Approaches to Development
The chapter contrasts two major ways to organize your development lifecycle:
### Feature Driven Development
* **Focus:** Developing specific features (e.g., "Support different terrains", "Allow units to move").
* **Process:** Pick a feature, code it, test it, repeat.
* **Pros:** Granular, easy to track progress on specific functionality.
* **Cons:** Can lose sight of the "Big Picture" or how users actually interact with the system.
### Use Case Driven Development
* **Focus:** Developing flows that help the user achieve a goal (e.g., "Place a unit on the board", "Move unit to new tile").
* **Process:** Pick a Use Case, code the logic to support that flow, test the flow, repeat.
* **Pros:** Ensures you are always building something of value to the user. Keeps the focus on the customer.
* **Cons:** Can be harder to track "backend" features that don't map 1:1 to a single user action.
**The Hybrid Approach:** In reality, you often mix both. You might start with Use Cases to define the big flows, but break them down into Features to write the actual code.
---
## 2. Testing: Proving It Works
You can't just say your code works; you have to *prove* it.
### Test Scenarios
* **Definition:** A specific situation you set up to verify that your code behaves as expected.
* **Context:** Before you write test code, you write "Test Scenarios" in plain English.
* **Example Scenarios for `Unit`:**
1. Create a unit with type "Infantry".
2. Give the unit a property "HitPoints" with value 25.
3. Change "HitPoints" to 15.
4. Try to get a property that doesn't exist (e.g., "Strength").
### Test Driven Development (TDD)
* **Concept:** Write the test *before* you write the code.
* **Workflow:**
1. Write a test case (it fails because the code doesn't exist).
2. Write the minimum code needed to pass the test.
3. Refactor if necessary.
* **Benefit:** It forces you to think about *how* your class will be used (its interface) before you worry about the implementation details.
---
## 3. Programming by Contract vs. Defensive Programming
The chapter explores two philosophies on how code should trust other code.
### Programming by Contract (Trust)
* **Philosophy:** "If you (the caller) set up the environment correctly, I (the method) promise to do my job. If you don't, all bets are off."
* **The Contract:** The method signature, comments, and return types form a contract.
* **Example:** If a method `moveUnit(Unit u)` expects a non-null Unit, it assumes the caller will verify the unit exists *before* calling the method. It might throw an unchecked exception (runtime error) if the contract is violated.
* **Use Case:** Good for internal code where you control both the caller and the callee.
### Defensive Programming (No Trust)
* **Philosophy:** "I don't trust anyone. I will check every input to make sure it's valid before I do anything."
* **Implementation:** Extensive null checks, range checks, and error handling inside every method.
```java
public void moveUnit(Unit u) {
if (u == null) {
return; // or throw Exception
}
// ... rest of logic
}
```
* **Use Case:** Essential for public APIs, libraries, or systems where you cannot control how external code calls your methods.
---
## 4. Finalizing the Unit Class (Commonality Revisited)
The team revisits the `Unit` class to handle dynamic properties efficiently.
* **The Problem:** Units need dozens of properties (speed, strength, ammo) that vary by game type.
* **The Solution:** A `Map<String, Object>` called `properties`.
* **Revised Unit Class:**
* `setType(String type)`
* `setProperty(String name, Object value)`
* `getProperty(String name)`
* **Why this works:** It separates the **Commonality** (all units have properties) from the **Variability** (which specific properties they have).
---
## 5. The UnitGroup Class (Composite Pattern)
Gary needs to group units (e.g., an "Army" is a group of "Soldiers").
* **Requirement:** A `UnitGroup` should behave like a collection of units.
* **Implementation:**
* `UnitGroup` stores a `Map` of Units (keyed by ID).
* It has methods like `addUnit()`, `removeUnit()`, `getUnit(id)`.
* **Design Note:** This is the beginning of the **Composite Pattern** (treating a group of objects the same way you treat a single object), though the book keeps it simple for now.
---
## Chapter Summary (Bullet Points)
* **Customers care about results.** They don't care about your UML diagrams; they care if the software solves their problem.
* **Iterate.** Don't try to build the whole system at once. Build a piece, test it, show it to the customer, and repeat.
* **Test Scenarios first.** Before coding, write down *what* you want to test. It clarifies your thinking.
* **Match tests to usage.** Your test cases should reflect how the code will actually be used in the real world (Happy Path + Alternate Paths).
* **Programming by Contract:** Use assertions and unchecked exceptions. Assume the caller knows what they are doing (efficient, but risky).
* **Defensive Programming:** Check everything. Assume the caller is broken (safer, but adds overhead).
* **Break it down.** Large problems (like "Build a Strategy Game") are solved by breaking them into small, testable classes (like `Unit` and `UnitGroup`).