On this page
A unit test covers unit behavior under specified conditions. Installer launch, vault preservation and live provider login have distinct acceptance paths.
Zortex is building a desktop product for macOS and Windows. The implementation includes a large collection of executable tests, installable package builders, platform-specific workflows and a separate connector acceptance harness. We pin the build being checked and keep source tests, platform installation and live-provider acceptance as distinct release gates.
The repository README states this explicitly: source code and fixture results are not sufficient to establish behavior on a user's installation.
Start with deterministic contracts
Fixtures are valuable because they make failures repeatable. The connector packages have test implementations of their source interfaces. An Apple Notes test can supply generated note identities and timestamps without asking the real Notes application to open. Gateway tests can simulate an authorized client and a revoked client without exposing a real account.
These tests answer narrow but important questions. Does an unchanged item preserve its identity? Does an incomplete listing avoid falsely deleting absent records? Does a policy grant deny an out-of-scope read? Does replay yield a stable projection?
They also give us a way to test failure behavior, which is often harder to reproduce in a live account. A provider timeout, corrupted cursor or unavailable layout must be distinguishable from a valid empty result.
Operating-system grants, live OAuth acceptance and installed-binary placement have separate acceptance checks.
Build the thing that would actually be installed
The unified candidates workflow binds a candidate to an exact main-branch commit and package version. It checks that the candidate version is not already occupied on the package registry. On macOS it builds the packages and carries their identified bytes to the Intel validation job; Windows has its own candidate path.
A candidate built from a different commit is a different artifact, even if the version string is unchanged. That is why an installation test should name the content being tested, not merely say “the latest build passed.”
Another platform installation workflow defines jobs for native Apple Silicon, native Intel and Windows x64. It builds installable packages and runs platform-aware smoke checks.
The trigger matters. This workflow is available on demand and for a specifically labeled pull request; it is not evidence of an automatic native run after every commit. Reading a workflow file demonstrates that the checks are configured, not that a particular release candidate has passed them.
Four distinct release checks
Source change
|
v
Unit, contract and replay tests
|
v
Pinned installable candidate
|
+----------+-----------+
| | |
v v v
Mac arm64 Mac x64 Windows x64
| | |
+----------+-----------+
|
v
Installed smoke and artifacts
|
v
Live connector acceptance
|
v
Release decision
Diagram: source tests, packaged installations and provider acceptance as separate release gates.
An installed smoke test checks more than a source import. The installed onboarding smoke, for example, uses a generated local browser-history fixture to exercise connection, retained source state and refusal after revocation. Real OAuth and version-to-version upgrades of existing installations are tracked as separate acceptance tasks.
That statement belongs near the result rather than in fine print. Otherwise “installed” can easily be misread as “tested against a real provider on a longstanding personal vault.”
Human login remains a separate test boundary
We maintain a dedicated connector Human Check for Windows acceptance. Its documented workflow selects a specific source version, runs authentication and connection steps, and attempts an actual data read. Depending on the provider, the test may open a browser and require a person to complete login, MFA or consent.
The tool records structured results and a readable HTML report. Its categories include PASS, FAIL, NEEDS_ATTENTION and NO_DATA. A successful command invocation alone does not mean the connector passed. The harness requires an actual record to be read for its successful read classification; an empty account needs a different interpretation.
Several modes answer different questions. A status-only run checks setup and diagnostics without proving real data access. A smoke-user run reuses the machine's existing user vault, so it is not a clean-install test and can update connection state. A smoke-installed run checks the binary on the current machine, not the exact source at a new GitHub tag.
A trustworthy report should carry these distinctions, the candidate version, the account/source scope and the failure stage. The report is a record of one run, not a universal certification.
Use incidents to improve the checks
Tests are most valuable when they preserve a counterexample we did not expect.
The connector investigation of September 21 identified missed refreshes after process restarts, stale provider status interpretation and a coverage mismatch that should not automatically imply corrupt identity. Those are reasons to test elapsed wall-clock age, capture source history and distinguish a source forgetting an item from duplicate ingest.
The source implementation also contains regressions for the ordinary but dangerous cases: cursor loss, revocation, interrupted work, stale layout, partial responses and identity collisions. The lesson is not that these defects can never recur. It is that once discovered, a failure needs a specific check that would make recurrence visible.
Make the release decision explicit
A useful release record should contain the source SHA, exact package bytes, operating systems exercised, tests that completed, tests that were skipped, and live-provider acceptance evidence where relevant. It should also preserve what was not tested.
The September compatibility audit provides an example of this discipline. It records generated-data regression and build checks, while tracking live-account acceptance, native macOS checks and package publication separately.
Our standard is not that every possible environment has been exercised. That would be an unsupported promise. It is that each release claim can be traced to the test that supports it, and that a missing real-machine check remains visible until somebody actually runs it.
The release record ties each pass to the source SHA, package, operating system and operation exercised. A skipped live-connector check is recorded as skipped rather than green.
Visual source: code-generated cover study.
