在此页面上

单元测试涵盖了指定条件下的单元行为。安装程序启动、保管库保留和实时提供商登录具有不同的验收路径。

Zortex 正在为 macOS 和 Windows 构建桌面产品。该实现包括大量可执行测试、可安装的软件包构建器、特定于平台的工作流和单独的连接器验收工具。我们固定正在检查的构建，并将源测试、平台安装和实时提供商验收作为不同的发布门。

存储库 自述文件 明确指出：源代码和夹具结果不足以确定用户安装上的行为。

从确定性合同开始

夹具很有价值，因为它们使故障可重复。连接器包包含其源接口的测试实现。Apple Notes 测试可以提供生成的笔记身份和时间戳，而无需请求真实的 Notes 应用程序打开。网关测试可以模拟授权客户端和已撤销客户端，而无需暴露真实账户。

这些测试回答了狭窄但重要的问题。未更改的项目是否保留其身份？不完整的列表是否避免错误地删除不存在的记录？策略是否拒绝了超出范围的读取？重放是否产生稳定的投影？

它们还为我们提供了一种测试故障行为的方法，这在实时账户中通常更难重现。提供商超时、损坏的光标或不可用的布局必须与有效的空结果区分开来。

操作系统授权、实时 OAuth 接受和已安装二进制文件的放置都有单独的接受检查。

构建实际将安装的东西

这 统一候选人工作流程 将候选版本绑定到精确的主分支提交和包版本。它检查包注册表中是否尚未占用候选版本。在 macOS 上，它构建包并将其识别的字节带到 Intel 验证作业；Windows 有自己的候选路径。

即使版本字符串未更改，从不同提交构建的候选版本也是不同的工件。这就是为什么安装测试应该命名被测试的内容，而不仅仅是说“最新构建通过了”。

另一个 平台安装工作流程 定义了适用于原生 Apple Silicon、原生 Intel 和 Windows x64 的作业。它构建可安装的软件包并运行平台感知的冒烟检查。

触发器很重要。此工作流按需提供，并适用于特定标记的拉取请求；它不是每次提交后自动本地运行的证据。阅读工作流文件表明检查已配置，而不是特定发布候选已通过检查。

四项不同的发布检查

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

工程测试真实机器的架构流程

图表：源测试、打包安装和提供商验收作为单独的发布门。

安装的冒烟测试检查的不仅仅是源导入。该 已安装的入职烟雾，例如，使用生成的本地浏览器历史记录夹具来练习连接、保留的源状态和撤销后的拒绝。真实的OAuth和现有安装的版本到版本升级被视为单独的接受任务。

该声明应放在结果附近，而不是放在细则中。否则，“已安装”很容易被误读为“已针对长期个人保管库中的真实提供商进行测试”。

人工登录仍然是一个单独的测试边界

我们维护一个专门的 连接器人工检查 用于 Windows 接受。其文档化的工作流程选择特定的源版本，运行身份验证和连接步骤，并尝试实际数据读取。根据提供商的不同，测试可能会打开浏览器并要求用户完成登录、MFA 或同意。

该工具记录结构化结果和可读的HTML报告。其类别包括PASS、FAIL、NEEDS_ATTENTION和NO_DATA。仅成功的命令调用并不意味着连接器通过。该工具要求实际读取记录才能进行成功的读取分类；空帐户需要不同的解释。

几种模式回答不同的问题。仅状态运行检查设置和诊断，但不提供真实数据访问。冒烟用户运行重用机器现有的用户保管库，因此它不是一个全新安装测试，并且可以更新连接状态。冒烟安装运行检查当前机器上的二进制文件，而不是新 GitHub 标签处的精确源。

一份值得信赖的报告应包含这些区别、候选版本、账户/来源范围和失败阶段。该报告是一次运行的记录，而非普遍认证。

利用事件改进检查

当测试保留我们未曾预料到的反例时，它们最有价值。

这 9月21日的连接器调查 识别了进程重启后遗漏的刷新、过时的提供商状态解释以及不应自动暗示身份损坏的覆盖不匹配。这些是测试经过的实际时间、捕获源历史记录以及区分源忘记项目与重复摄取的原因。

源实现还包含普通但危险情况的回归：光标丢失、撤销、工作中断、布局过时、部分响应和身份冲突。教训不是这些缺陷永远不会再次发生。而是，一旦发现，故障需要一个特定的检查，以使再次发生可见。

明确发布决定

有用的发布记录应包含源 SHA、确切的包字节、已执行的操作系统、已完成的测试、已跳过的测试以及相关的实时提供商验收证据。它还应保留什么 不 已测试。

这 九月兼容性审计 提供了这种规范的一个示例。它记录了生成数据回归和构建检查，同时分别跟踪实时帐户验收、原生 macOS 检查和包发布。

我们的标准并非所有可能的环境都已得到验证。那将是一个无法支持的承诺。我们的标准是，每个发布声明都可以追溯到支持它的测试，并且缺失的真实机器检查在有人实际运行它之前仍然可见。

发布记录将每次通过与源 SHA、包、操作系统和执行的操作关联起来。跳过的实时连接器检查被记录为跳过而不是绿色。

视觉来源： 代码生成的封面研究.