One useful idea
A boundary is the seam where your code meets another contract: input values, a provider response, or filesystem bytes. A unit test isolates a small pure behavior such as numeric ordering. A contract test checks the exact shape your adapter promises. An integration test exercises components together and observes the actual file. These names describe what you observe, not how many mocks or assertions appear.
collect_jobs accepts an exact list of at most 1,000 distinct IDs, each 1..64 ASCII letters/digits/underscore/hyphen. Validate the entire request before the first provider call. A response has exactly id and status, with the requested ID and one of queued/running/done/failed. Extra fields, mismatched IDs, boolean status and unknown values are refused, not guessed or silently discarded. Return fresh rows in request order; provider errors remain visible. An empty request needs no call.
The Provider protocol documents get_job(job_id); it does not make a network connection or validate values at runtime. An invented FakeProvider lets you control rows, record requested IDs and inject a failure. These observations establish only our declared fixture contract. They do not prove that a real vendor, changing API, authentication flow, timeout or server behaves the same. This module needs no live credentials or provider requests.
One integration uses reviewed save_snapshot to create a NEW JSON file, then reads its actual values and checks bytes/hash. A planned JSON string or file existence is not enough. Preflight rejects bad rows, known links/reparse points, traversal, reserved names, missing parents and existing destinations. The helper creates no parent folders and overwrites nothing. A write/read failure may leave partial NEW output, without a verified receipt, automatic cleanup or rollback. This is not hostile-filesystem race isolation.
You own collection/preflight/schema traversal and your test map; schema/file helpers are reviewed assistance. Keep fixture records invented. A machine status failed is not an authored creative-quality rating. Use the boundary-map and transfer template to record each observed seam and what remains untested, rather than counting green mocks as full integration coverage.
Refresh first: Assertions and regression evidence, Fake-provider HTTP boundaries, Actual file roundtrip.
Trace a finished example
import json
from pathlib import Path
from tempfile import TemporaryDirectory
from quality_tools.core import collect_jobs
from quality_tools.files import save_snapshot
class FakeProvider:
def __init__(self):
self.calls = []
self.rows = {"shot_A": {"id": "shot_A", "status": "done"},
"shot_B": {"id": "shot_B", "status": "running"}}
def get_job(self, job_id):
self.calls.append(job_id)
return self.rows[job_id]
provider = FakeProvider()
rows = collect_jobs(provider, ["shot_B", "shot_A"])
print(provider.calls)
with TemporaryDirectory(prefix="dvp-owned-boundary-") as temporary:
path = Path(temporary) / "new.json"
receipt = save_snapshot(rows, path)
print(json.loads(path.read_text(encoding="utf-8")) == rows, receipt["verified"])
before = path.read_bytes()
try:
save_snapshot(rows, path)
except ValueError:
print("overwrite refused", path.read_bytes() == before)
rows[0]["status"] = "edited"
print(provider.rows["shot_B"]["status"])Expected output
['shot_B', 'shot_A']
True True
overwrite refused True
runningThe fake records actual request order. The reviewed integration writes and reads one real JSON file in an owned temporary example folder, refuses reusing it, then shows fresh row ownership. TemporaryDirectory cleans only that example’s own folder; learner artifacts and partial outputs are not deleted.
The finished implementation is in quality_tools/core.py. Reading it is guided practice, not independent evidence.
Choose the observation
Is a mocked open call enough to prove JSON was written and read correctly?
Compare your answer · self-reviewed
No. It can observe an interaction but not actual filesystem bytes and typed roundtrip. This integration creates a NEW file, reads it and checks the receipt.
Find the preflight bug
The second ID is invalid but the first provider call already ran. What is wrong?
Compare your answer · self-reviewed
The whole bounded request must validate before effects. Validate all IDs and uniqueness first, then call the provider in the declared order.
Recall meaning
Does a returned provider status failed prove the video has poor motion?
Compare your answer · self-reviewed
No. It is supplied machine metadata about a job, not an authored criterion rating or verified media defect. Preserve the distinction.
Change it, then build your own
One controlled change
Reverse the requested IDs and set a different valid status. Then try an extra response field, a foreign ID and an invalid second request ID. Predict call order, fresh values or refusal before executing.
Your independent task
Implement collect_jobs with the disclosed _ids/_job schema helpers or your own equivalent checks, but own the ordered provider traversal and fresh rows. Write a boundary map plus one pure/unit test, one invented-provider contract test and one actual NEW-file roundtrip using reviewed save_snapshot. Declare helper assistance and what real-service/filesystem behavior is not established.
What success looks like
Build 2 public checks protect request preflight/order, exact response shape, fresh ownership, empty/failing provider behavior and real-file roundtrip/no overwrite. Your written map names each observation and its limits. A fake success or byte receipt cannot award live-provider compatibility, privacy or portfolio completion.
Hint 1 · a question
Draw function → declared provider seam → NEW file. Which observation belongs to a unit, a contract and an integration test?
Hint 2 · a concept cue
Check the whole ID list before iteration with effects. Validate each response against its requested ID before adding a fresh row to ordered output.
Hint 3 · a localized example
Read the actual JSON after writing and compare values/order, byte count and hash. The reviewed file helper supplies this assistance; name it in your test map.
Need the complete worked solution?
Open quality_tools/core.py from the kit. Trace it, close it, then try fresh inputs in your own files. Treat the attempt as guided; seeing the solution does not award a practical pass.
Course help is guidance, not independent evidence. With JavaScript, opening help records guidance locally; otherwise note it in your README. Reset does not erase that history.
Repair a failed check
If unknown fields vanish, enforce the exact schema instead of projecting a convenient subset. If a malformed request partly calls the provider, move all request validation before effects. If source rows mutate, return fresh mappings. If an existing snapshot is reused, choose another explicit NEW filename and keep the old evidence untouched.
NotImplementedError means a practice stub is still unfinished. Read the failing test name and the last error line. Change one behavior, rerun that build, then rerun all implemented builds.
Show it works on new inputs
Create a new three-ID fake, change its statuses/order and add one malformed response. Retain your authored tests, observed calls, a NEW-file roundtrip and completed boundary map. Explain why more mocked interactions cannot replace the actual file observation, and why the fake says nothing about live vendor compatibility.
Self-review: name the input, result, refused case and reason. Your local test output and explanation are separate from a quiz score; this page does not certify a pass.
Keep the idea
Test the seam you depend on, and name the seam you have not tested. Honest scope makes green results more useful.