Challenge 2: Testing the Complete Logic — Possible Solution
====================================================================

fn complete_task(tasks: &mut Vec<Task>, id: u32) -> Result<(), TaskError> {
    let task = tasks.iter_mut().find(|t| t.id == id).ok_or(TaskError::NotFound(id))?;
    task.completed = true;
    Ok(())
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn completing_a_valid_task_sets_completed_true() {
        let mut tasks = vec![
            Task { id: 1, description: String::from("Buy milk"), completed: false },
        ];

        complete_task(&mut tasks, 1).unwrap();

        assert!(tasks[0].completed);
    }

    #[test]
    fn completing_an_invalid_id_returns_not_found() {
        let mut tasks = vec![
            Task { id: 1, description: String::from("Buy milk"), completed: false },
        ];

        let result = complete_task(&mut tasks, 99);

        assert!(matches!(result, Err(TaskError::NotFound(99))));
    }
}

WHY THIS WORKS AS AN ANSWER
------------------------------
The Complete logic is first extracted into its own standalone
complete_task function, taking &mut Vec<Task> and the target id
directly — this is necessary because the original logic lived inline
inside main()'s match block, which isn't independently testable;
pulling it into its own function is a genuine, common refactor for
making CLI logic unit-testable, per Course 2 Chapter 7's own
same-file #[cfg(test)] convention.

The first test builds a small Vec<Task> directly (no real file I/O,
no Storage trait involved at all — this is a pure, isolated UNIT test
of the completion logic itself), calls complete_task with a valid id,
and asserts the task's completed field actually flipped to true.

The second test verifies the NotFound error path directly, using
Rust's matches! macro to assert the returned Result is specifically
Err(TaskError::NotFound(99)) — a more precise, more informative
assertion than a bare #[should_panic] would provide here, since
complete_task returns a Result rather than panicking on a missing id,
matching this chapter's own "don't unwrap in real CLI logic" guidance:
the failure path is a genuine Result value to test explicitly, not a
panic to merely detect.