Write the Tests That Catch the Bug

Everything so far asked you to write the code. This one hands you the code and asks for the tests — because on a team, the tests are how you find out whether the code is right, and writing a test that actually catches a bug is a different skill from writing a function.

chunk_document(text, chunk_size, overlap) is already implemented and correct. Its contract:

1. Each chunk holds at most chunk_size words.
2. Each chunk after the first starts overlap words before the previous one ended.
3. Chunks are strings, words rejoined with single spaces.
4. Never an empty chunk, and never a chunk whose words are all already covered by the previous one.
5. Empty or whitespace-only input returns [].

Write functions named test_* that call chunk_document and assert on the result. Nothing else — no return values, no printing.

You are graded two ways, in order:

First, your tests must pass against the correct implementation. A test that fails on working code is not a test; it is a bug report against yourself.

Then, your tests are run against six broken versions — each with one realistic bug, each breaking one clause above. A broken version is caught when at least one of your tests fails on it. You never see the broken code; you see which ones your tests let through.

A test of the happy path catches the crude bugs. Catching all six means testing each clause on its own: uneven lengths, the tail, empty input, repeated whitespace. That is the job.