Writing Testable Code

# CHAPTER 12

Writing Testable Code #

1. Introduction #

2. Learning Objectives #

• Identify code that is impossible to test (Tightly Coupled).

• Understand and implement Dependency Injection (DI).

• Define "Loose Coupling" and its relationship to testability.

• Utilize "Mocks" to simulate external systems (databases, APIs) during testing.

• Write clean, expressive Unit Tests using the Arrange-Act-Assert pattern.

3. The Enemy of Testing: Tight Coupling #

class OrderProcessor {
    public function process($order) {
        // TIGHT COUPLING! We cannot test this without a real MySQL database!
        $db = new MySQLDatabase(); 
        $db->save($order);
        
        // TIGHT COUPLING! We cannot test this without sending a real email!
        $mailer = new SmtpMailer(); 
        $mailer->send("Order Processed");
    }
}

If you write a unit test for OrderProcessor, it will actually insert data into a database and send a real email. That is not a unit test; that is a dangerous integration test.

4. The Solution: Dependency Injection (Loose Coupling) #

class OrderProcessor {
    private $db;
    private $mailer;

    // We INJECT the dependencies.
    public function __construct(DatabaseInterface $db, MailerInterface $mailer) {
        $this->db = $db;
        $this->mailer = $mailer;
    }

    public function process($order) {
        $this->db->save($order);
        $this->mailer->send("Order Processed");
    }
}

5. Mocking (Faking Dependencies) #

public function testOrderProcessing() {
    // 1. Arrange: Create FAKE dependencies
    $mockDb = new MockDatabase();
    $mockMailer = new MockMailer();
    $processor = new OrderProcessor($mockDb, $mockMailer);

    // 2. Act: Run the logic
    $processor->process($testOrder);

    // 3. Assert: Check if the fake database was called
    $this->assertTrue($mockDb->wasSaveCalled());
}

*Result:* The test runs in 0.001 seconds, requires no internet connection, and never touches a real database.

6. The Rules of Clean Tests (F.I.R.S.T) #

• Fast: Tests must run in milliseconds. If they take 10 minutes, developers will stop running them.

• Independent: Test A must not depend on Test B. They can be run in any order.

• Repeatable: Tests must produce the exact same result in any environment (your laptop, the CI server) without network/database dependencies.

• Self-Validating: Tests output a binary result: Pass or Fail. You should not have to read a log file to see if it worked.

• Timely: Tests should be written just before the production code (Test-Driven Development).

7. Diagrams/Visual Suggestions #

public function testDiscountCalculation() {
    // ARRANGE (Set up the data)
    $calculator = new DiscountCalculator();
    $cart = new Cart(total: 100);

    // ACT (Execute the function being tested)
    $result = $calculator->applyVipDiscount($cart);

    // ASSERT (Verify the expected outcome)
    $this->assertEquals(80, $result);
}

8. Best Practices #

• Test Behavior, Not Implementation: Do not write tests that check *how* a function does its job (e.g., checking if an array was sorted). Test *what* the result is. If you test implementation details, your tests will break every time you refactor the code (Brittle Tests).

9. Common Mistakes #

• Testing Private Methods: Developers often try to write unit tests for private helper methods. This is an anti-pattern. You only test the public API of a class. If the private method is complex enough to need its own test, it should be extracted into its own separate class where it becomes public.

10. Mini Project: Refactor for Testability #

class ConfigReader {
    public function read() {
        // Hardcoded file path and hard drive access!
        return file_get_contents("/etc/config.json");
    }
}

*Testable (Dependency Injection):*

interface FileReader { public function getContents(string $path): string; }

class ConfigReader {
    private $reader;
    public function __construct(FileReader $reader) { $this->reader = $reader; }
    
    public function read() {
        return $this->reader->getContents("/etc/config.json");
    }
}
// Now, in a test, we can pass a MockFileReader that just returns a dummy string!

11. Practice Exercises #

1. 1. Define "Tight Coupling." Why does tight coupling make unit testing mathematically impossible without relying on Integration Testing?

1. 2. Explain the "Arrange, Act, Assert" pattern used in writing clean unit tests.

12. MCQs with Answers #

13. Interview Questions #

• Q: "The new keyword is glue." Explain this phrase. How does instantiating an object inside a method destroy testability?

• Q: Explain the difference between testing the "Public API" of an object versus testing its internal implementation details. Why do implementation-focused tests lead to "Brittle" test suites?

• Q: Walk me through the F.I.R.S.T principles of clean testing. Why is it absolutely critical that Unit Tests execute in milliseconds?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #