用户反映更新后 API token 被清空、需要重填。根因不在安装器(它早已用 onlyifdoesntexist 且清理时保留 config.toml / config.base.toml,从不覆盖用户 配置),而在 Server 启动时的合并路径 SyncConfigWithInstalledTemplate:当 config.toml 存在、非空但解析不过(上次写入被打断留下半截文件,或 token 里混入 破坏 TOML 的字符)时,旧逻辑直接拿出厂模板覆盖,等于把用户全部配置——尤其是 凭证——清零。 配置升级本质上已经是「逐条把用户值重放到新模板」(MergeTomlIntoTemplate),因此 不另建配置操作日志,而是把「逐条重放」精准用在最难重填的凭证上,并堵掉硬重置: - ReapplyRealCredentials:合并结束时把用户填过真值的凭证逐条重放回去,有键改值、 无键则在其分节插入。覆盖 token / api_key / apikey / secret_id / secret_key / app_id / asr_app_key 及所有 per-provider 槽位(token_* / asr_token[_*] / polish_token[_*]),真值判定复用 VoiceInput::IsPlaceholderToken。这样模板漂移 漏掉某个 token 键也不会静默丢失;占位符不粘住,新默认值照常生效。 - SyncConfigWithInstalledTemplate 的 unparseable 分支:先把坏文件备份成 config.toml.corrupt-<时间戳> 留证,再逐行抢救可识别赋值重放到新模板;即便整体 抢救结果仍解析不过,也只回退到「模板 + 重放凭证」,而非纯模板。 新增回归测试:模板漏键时真 token 被写回、未填的占位符跟随新默认、损坏配置能捞回 真 token,以及读安装器真正分发的 config.default.toml 逐分节确认所有凭证键挺过升级。
Tests
This project now includes a lightweight regression test target wired into the main CMake build.
What It Covers
Current tests focus on high-value IME behaviors that are easy to accidentally break during refactors:
shuangpinscheme request constructionquanpinscheme request construction- case-preserving shuangpin segmentation
- full-helpcode detection
engine + shuangpincontinuation behavior- cloud suggestion trigger timing for shuangpin
The goal is not to fully simulate the whole IME UI pipeline yet. The goal is to protect the core input rules and session behavior.
Build and run
Run these commands from the MSIME-Windows repository root after preparing
vcpkg and Boost with python server/scripts/prepare_env.py:
python scripts/product_lock.py fetch-dictionaries --staging-root .
if ($LASTEXITCODE -ne 0) { throw 'Dictionary verification failed' }
$env:LOCALAPPDATA = Join-Path $PWD 'build/test-data/user-local'
$env:METASEQUOIA_IME_DATA_DIR = Join-Path $env:LOCALAPPDATA 'metasequoiaime'
New-Item -ItemType Directory -Force $env:METASEQUOIA_IME_DATA_DIR | Out-Null
Copy-Item MetasequoiaImeDict/out/* $env:METASEQUOIA_IME_DATA_DIR -Force
Copy-Item engine/helpcode/helpcodes $env:METASEQUOIA_IME_DATA_DIR -Recurse -Force
Copy-Item server/assets/tables/* $env:METASEQUOIA_IME_DATA_DIR -Force
Copy-Item server/assets/config/config.toml $env:METASEQUOIA_IME_DATA_DIR -Force
.\server\tests\scripts\llaunch.ps1 -Configuration Release
Use a dedicated PowerShell terminal: these environment variables isolate both Windows helpers and the shared Engine from the installed user's data for the rest of that session. The scripts run CTest; they do not launch the interactive Server, install or register the input method. CI additionally runs the native Win32/x64 pipe probe after building the full Server.
Tests belong to the Server CMake project, which provides the Engine, GUI and
third-party targets. server/tests/CMakeLists.txt is an add_subdirectory input,
not an independent project. The obsolete test presets have been removed; an old
locally generated server/tests/CMakePresets.json is no longer used.
Once test data is prepared, the convenience scripts work from any directory:
.\server\tests\scripts\llaunch.ps1 -Configuration Release # build, then CTest
.\server\tests\scripts\lrun.ps1 -Configuration Release # CTest only
Omitting -Configuration selects Debug in server/build; Release uses
server/build-release. Both compile MetasequoiaImeServerTests and
test_webview_contract in the parent build tree. Configuration, compilation,
test failures and an empty CTest registry return failure rather than launching a
stale executable or reporting success.
The equivalent direct CTest command from the repository root is:
ctest --test-dir server/build-release -C Release --output-on-failure --no-tests=error
Test Layout
tests/src/main.cpp- tiny custom test runner
tests/includes/test_framework.h- lightweight assertion helpers
tests/src/test_shuangpin_scheme.cpp- shuangpin scheme unit tests
tests/src/test_quanpin_scheme.cpp- quanpin scheme unit tests
tests/src/test_shuangpin_query.cpp- query/helper function tests
tests/src/test_engine_shuangpin_session.cpp- session-level behavior tests
Recommended Practice
When you change input behavior, add a regression test if the change affects:
- input segmentation
- space/enter/backspace behavior
- helpcode handling
- continuation after candidate selection
- create-word flow
- cloud suggestion timing
The best tests in this project are the ones that capture a concrete input example that previously broke.