Exercise 1: A Real Test Confirming toggleDone(for:) Flips isDone — Possible Solution
===========================================================================================

import Testing

@Test func togglingATaskFlipsItsDoneState() {
    let viewModel = TaskListViewModel(apiClient: FakeAPIClient())
    viewModel.add(title: "Buy milk", priority: 1)

    let task = viewModel.tasks[0]
    #expect(task.isDone == false)

    viewModel.toggleDone(for: task)

    #expect(viewModel.tasks[0].isDone == true)
}

HOW IT WORKS: The test creates a real TaskListViewModel using
FakeAPIClient() (Chapter 5), then calls the real add(title:priority:)
method to insert one task - correctly leaving isDone at its own real
default value of false, confirmed by the first #expect. Note that
task is captured as a value BEFORE toggling (Task is a struct, per
Fundamentals Chapter 4), so task.isDone itself never changes - the
test correctly re-reads viewModel.tasks[0] afterward, rather than
checking task.isDone again, since the ORIGINAL captured copy would
still show isDone == false regardless of what toggleDone(for:) does
to the ViewModel's own array.

Calling viewModel.toggleDone(for: task) reuses the real method already
defined on TaskListViewModel, which locates the matching task by id
and flips its own isDone property inside the ViewModel's own tasks
array. The second #expect re-reads viewModel.tasks[0] fresh, correctly
confirming the actual stored task's own isDone is now true.

ANSWER: A @Test function creating a TaskListViewModel with
FakeAPIClient(), adding one task, confirming it starts as
isDone == false, calling toggleDone(for:), and confirming
viewModel.tasks[0].isDone == true afterward correctly verifies the
toggle behavior - re-reading the array each time rather than reusing a
stale captured struct copy.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly writes a real Swift Testing @Test function using
FakeAPIClient for dependency injection, and correctly re-reads the
ViewModel's own array after mutation rather than checking a captured
struct value that Chapter 4's own value-type semantics would leave
unchanged.