发布前的 Smoke Test

Wox 这类跨平台桌面应用，本身就有不少容易出问题的连接点: Go 后端、Flutter 桌面 UI、插件宿主、设置、存储，还有不同平台上的行为差异。开发速度一快，最容易出问题的地方也更明显了: 某个改动单独看没什么问题，但一跑真实启动链路，应用就不对了。

所以我们给 Wox 补了一道发布前的 smoke test，不是去验证某几个零散模块，而是直接把应用最关键的启动和交互路径跑一遍。

这套流程放在 wox.test/ 下。runner 会先启动一个真实的 wox.core 开发实例，把它指向隔离的数据目录，等待 /ping 可用，然后再去跑 Flutter 桌面端的 integration_test。每次运行都会生成独立的产物目录，日志和相关文件都会留下来，出了问题之后可以直接回看，而不是靠猜。

它看起来不复杂，但有几个细节是必须做的。首先，WOX_TEST_DATA_DIR 和 WOX_TEST_USER_DIR 会被重定向，保证 smoke test 不会污染开发者本地正在使用的数据。其次，runner 会优先尝试开发阶段常用的 34987 端口，如果端口被占用，就自动切到空闲端口。再往下，它不会凭时间估算后端“差不多该起来了”，而是明确等到 http://127.0.0.1:<port>/ping 真正可达之后，才开始 UI 测试。整个过程中 telemetry 会关闭，core.log 和 flutter_test.log 也会一起保存。

这些实现细节比“写了多少测试”更重要。Smoke test 要能当门禁用，重点不是看起来完整，而是要隔离、可重复，并且失败之后能定位。

第一批用例放在 wox.ui.flutter/wox/integration_test/launcher_smoke_test.dart，覆盖的是最容易影响用户感知的那几条路径: Launcher 能不能正常显示，查询框能不能输入，搜索结果能不能用键盘上下移动，设置页能不能从主界面打开，几个基础设置页面能不能切换和关闭，主题、数据、usage、about 这些入口还在不在。

这已经足够回答一个很实际的问题: 现在这次改动之后，Wox 还像不像 Wox，能不能正常起来，能不能把最基本的事情做完。

我们并不打算把 smoke test 做成一套庞大的体系。它的任务很单纯: 在最后一道门上，替我们把真实应用跑一遍。改动速度越快，尤其是在 AI 参与越来越多之后，这种基于真实运行结果的信心就越重要。对 Wox 来说，这套 smoke flow 就是发布前最后那一下确认。