Exercise 3: Why #expect's Non-Fatal Default and #require's Fatal Default Both Make Sense — Possible Solution
=====================================================================================================================

#expect being non-fatal is the correct real default whenever a test is
checking several genuinely INDEPENDENT facts about the same result,
and each one is worth knowing about on its own regardless of whether
the others pass or fail. The chapter's own
addingATaskIncreasesTheCount() test is a real, concrete example: it
checks both viewModel.tasks.count == 1 AND
viewModel.tasks.first?.title == "Buy milk" as two separate #expect
calls. If the count check failed but the title check would have
passed, a non-fatal #expect still reports both real results separately
- stopping after the first failure would have hidden the fact that
the title itself was actually correct, giving a real, less complete
picture of what genuinely went wrong.

#require being fatal is the correct real default specifically when a
later part of the SAME test genuinely cannot proceed meaningfully
without the checked condition being true first. The chapter's own
theFirstTaskHasTheExpectedTitle() test is the concrete example: if
viewModel.tasks.first were actually nil, there would be no real
firstTask value at all for the following #expect(firstTask.title == ...)
to even check - continuing anyway would either crash outright (the
exact real force-unwrap risk the chapter's own warn-box named) or
require writing awkward extra nil-handling code just to keep the test
running pointlessly past a condition that already disproved the whole
premise being tested.

The real, general pattern: #expect fits checking several independent
facts where partial information is still genuinely useful; #require
fits a precondition an entire rest of the test genuinely depends on,
where continuing past a failure wouldn't produce any further
meaningful, safe result anyway.

ANSWER: #expect's non-fatal default fits checking several independent
facts in one test - as in the chapter's own count-and-title example -
since a failure in one check shouldn't hide real information from the
others. #require's fatal default fits a precondition the rest of the
test genuinely can't proceed without - as in the chapter's own
first-task-unwrapping example - since continuing past a failed
#require would mean either a real crash or working with data the test
itself has already shown to be invalid.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the real, general distinction (independent checks vs.
a genuine precondition for the rest of the test) and grounds it in one
concrete example of each from the chapter itself, rather than treating
the two macros as arbitrarily different.