Read a Mock Demo Before Accepting an Integration

A local preview can show the intended interaction while its service response is still a fixture. That can be a useful prototype. Before accepting the larger task, identify which parts actually ran and which result the fixture supplied.

Ask a concrete question: when the view says “Saved,” did the application display a supplied success value, call the intended adapter, receive a real service result, or verify the value on a later read? Those are different pieces of evidence.

Python's mock documentation describes replacing parts of a system under test and asserting how replacements were used. That is a useful testing technique. A check against the replacement establishes a claim about that test path; it does not observe the replaced service.

Separate the full request from the prototype milestone

Consider this fictional request for a notebook application:

Task NOTE-5: let a permitted user change N17's label from Draft to Ready.

Full workflow:
Show Saved only after the actual service confirms the change.
When the user reopens the record, read its current saved label.
If saving fails, explain that it was not saved and keep the proposed
label available for correction. Use the application's existing access
checks; do not invent a new permission model.

First delivery only:
Prepare inspectable local prototype source with a fixture response,
an explicit no-service label, a boundary diagram and a check of the
fake-response state model. Record browser checks not run.
Do not connect a service, use real records or deploy this milestone.

This request permits a prototype without defining it as the complete integration. Reviewing those two deliveries separately avoids both rejecting useful prototype work and accepting a service path that has not been exercised.

Everything in this case is authored teaching material: record N17, the request, fixture, component and review replies. No real record or provider is involved.

Follow the supplied success value

The starting fixture is:

{"record_id":"N17","label":"Draft"}

The fake adapter returns this separate synthetic response when asked to save:

{"record_id":"N17","label":"Ready","saved":true}

It does not contact a service. In this pure Python teaching analogue, the entire adapter and local model are:

class FakeLabelAdapter:
    def __init__(self):
        self.calls = []

    def save_label(self, record_id, label):
        self.calls.append((record_id, label))
        return {"record_id": record_id, "label": label, "saved": True}


class DemoPanel:
    def __init__(self, adapter):
        self.adapter = adapter
        self.label = "Draft"
        self.notice = "Not saved"

    def save(self):
        response = self.adapter.save_label("N17", "Ready")
        self.label = response["label"]
        self.notice = "Saved" if response["saved"] else "Not saved"

The saved field is true because the fake returns true. The model's notice follows that field. There is no storage write hidden elsewhere in this small example.

The accompanying standalone HTML prototype supplies a corresponding local interaction, visibly labeled LOCAL MOCK DEMO · NO NETWORK OR STORAGE. It contains no service call and resets its displayed label when Reopen fixture is selected. Its browser behavior has not been run as part of this article. The Python analogue's method checks are separate from a browser click or rendered-page check.

Draw the boundary before judging the demonstration

If someone runs a real local preview and sees Ready, that observation can support rendering with the supplied fixture. It still does not establish a service save. For the files supplied here, even that rendering observation remains unperformed; the picture above is a boundary schematic, not a browser capture.

Check what the small model actually does

The local teaching run used Python 3.9.6 and checked two things:

1. Calling save() records exactly ("N17", "Ready") in the fake and changes that model's state to Ready / Saved.
2. Creating a new model with the same adapter starts again at Draft / Not saved. The adapter still records one call; it has not provided a saved-record read.

Both model checks passed. They do not run the HTML, JavaScript, browser, service, authentication or storage. Their actual output is retained in the local model log.

Here is the state history, with the observations kept narrow:

Step 4 is a property of this authored prototype, not an observed failure of a real service. The model was built to initialize from Draft and has no persistence. It would be misleading to report “the backend lost the save.” No backend was contacted.

The fake remains useful. It lets a developer inspect the response branch and check its intended call without service setup. A different fixture could also exercise a failure branch, but this supplied prototype does not implement NOTE-5's full failure handling. That is an identified next task, not a completed check.

Match each acceptance claim to the right evidence

An integration decision need not demand every possible test. It needs the evidence relevant to the promised boundary. For this request, the essential missing span is from the actual adapter through the service to a later read, together with its failure and access behavior. Repeating the fixture-only check does not cross that span.

Write two different acceptance replies

The first reply accepts the milestone that was actually requested:

Accept the NOTE-5 prototype-source and fake-state-model milestone.

The supplied HTML is explicitly marked as a no-service mock demo.
The boundary diagram identifies the fake and unexercised service path.
The recorded Python checks establish the fake call arguments and local
state transition, including the new model's reset to Draft.

This decision covers those source/model artifacts. Browser interaction
was not checked, and the actual save/read/access/failure path is not
implemented or accepted. Keep the full NOTE-5 workflow open.

The second reply addresses a proposed claim that the full integration is finished:

Do not close the end-to-end NOTE-5 task from the mock demo.
Its saved=true value comes from the fake response, not a service result.

Next, identify the actual adapter, save operation and subsequent-read
path in the selected codebase. Return a bounded integration plan with
the exact candidate/files, applicable access checks, failure behavior
and the smallest relevant verification steps.

Keep prototype evidence labeled as such. Do not replace it with invented
service output or repeat the local fake check as proof of persistence.
Any later real-environment check must use its authorized scope and data.
No service call, account setup, live record change or release is requested
by this planning reply.

Neither reply treats mocking as a defect. One accepts a useful limited artifact; the other preserves the unmet part of the original request.

Reuse this demonstration-review request

Review [exact demo candidate] against [the original requirement and
the milestone currently being accepted]. Work read-only.

Trace the demonstrated action from input through local state, adapter,
dependency, saved result and later read where relevant. Mark each stage:
actually exercised, simulated, source-inspected only or not established.
Identify the exact fixtures and supplied success/failure values.

For every claim, state what the demonstrated path can support and which
boundary it does not cross. A fake-call assertion can support a call
contract; it must not be reported as observing the replaced service.
An authored picture or unrun HTML must not become a browser test result.

Return a bounded decision for the current milestone and the smallest
next plan/check for any larger unmet requirement. Preserve useful mock
checks. Do not call accounts, change live data, install services or deploy
as part of this review. Record actual execution separately from examples.

This makes a demo easier to use well. You can accept the part it establishes, retain the fixture for later development and request the specific evidence needed for the next boundary.