Running actual Electron and Python does not make the web service real. Opening a public site does not verify every upload and publication journey either. Reviewing the browser's tests taught me to ask separately whether the executor, page and business result were actual or substituted.
A controlled page makes a failure condition reproducible
Project-isolation launches actual Electron in an independent profile while replacing HTTPS responses with owned HTML. Input produces a completion marker after a fixed delay, and two projects run together. Controlling the response makes overlapping execution reproducible.
That does not make the entire execution fictitious. Real kernels, tabs and run IDs are subjects of the test; the external page response is substituted. State which layer is real and which is replaced. Otherwise a reader can mistakenly assign the fixture's timing and structure to a public service. Controlled evidence is valuable precisely because its conditions are explicit.
A receiver separates selection from transmitted bytes
Synthetic files and a local receiver make names, empty files, multiple selection and clearing reproducible. Comparing received bytes examines a more concrete boundary than an attachment label alone. A file hash has a clear role within that transfer check.
The bytes reaching a local receiver do not establish that an external AI service can interpret a ZIP. A separate live Gemini result records inability to read the archive. Receiving and understanding are different layers. A later text conversion with a verification code supports that converted input, not a claim that the original archive format was supported. Keep the input transformation in the evidence chain.
Live sites expose conditions controlled by someone else
The historical public-site audit records specific actions such as opening home pages, search, history navigation and player progress. Google search reached an external verification screen, so ordinary results remained unverified. The audit did not bypass that screen or solve a CAPTCHA to increase a success count.
Video playback progress also differs from successful advertisement skipping. Opening one site cannot establish compatibility with all its features. Fixtures cannot answer account and server limitations controlled elsewhere. These records are historical observations tied to versions, not promises that every current account behaves the same way.
Distinguish a test defect from a product defect
The public-site audit retained early failures caused by a hidden window and unstable locators. It then reran with a visible window, explicit navigation waits, actual labels and a visible video. It did not rewrite the initial attempt as an uninterrupted success.
Product issues such as an intermediate HTTPS navigation and misreported subframe failures were separate fixes. A broken test cannot explain every product failure. Record which hypothesis changed and which source changed. That makes a passing rerun informative: it identifies whether reproduction conditions or implementation caused the difference, rather than merely replacing a red result with a green one.
Connect evidence without merging its meanings
My verification sentences name executor, page, server and result stage. An actual Electron run against an owned fixture is described exactly that way. An actual server response is linked to its version and input. Inspecting an existing result without sending new material is labeled separately too.
This article compares historical reports and tests without creating new service requests. The shared failure lab is a controlled in-memory model, not certification of live compatibility. Combining controlled and live evidence becomes stronger when each retains the questions it can answer. Explaining which part was actual is more informative than placing the word real in front of the whole test.