Exercise 2: Testing computeFullPath() — Possible Solution
====================================================================

THE FUNCTION UNDER TEST
------------------------------
Per this chapter:

async function computeFullPath(slug, parentId) {
  if (!parentId) return slug;
  const parent = await basePrisma.page.findUniqueOrThrow({ where: { id: parentId } });
  return `${parent.fullPath}/${slug}`;
}

CASE 1: A PAGE WITH NO PARENT
------------------------------
computeFullPath('about', null) returns 'about' directly - the !parentId
check short-circuits before any database query runs at all. This
matches a genuine top-level page.

CASE 2: A PAGE WITH A REAL PARENT
------------------------------
Given an existing page with id 5 and fullPath 'programming', calling
computeFullPath('python', 5) looks that parent up via
findUniqueOrThrow, reads its fullPath ('programming'), and returns
'programming/python' - the parent's own already-computed full path,
with the new slug appended after a single slash.

CONFIRMING BOTH CASES
------------------------------
Both results can be confirmed either by calling computeFullPath()
directly in a test script and logging the return value, or by creating
a page through the page.create() call (which triggers this function
automatically via the Client Extension) and then querying the created
row's own fullPath column to confirm it matches.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly traces both branches of the function - the early return
for a parentless page and the parent-lookup-plus-concatenation path for
a nested one - and verifies the nested case builds on the parent's own
already-correct fullPath rather than recomputing the whole path from
scratch, which is exactly what makes the materialized-path half of this
chapter's own hybrid design cheap to read.