WASM 模块测试与模糊测试：从单元测试到差分验证

        ┌─────────────────────┐
        │ 端到端（真实浏览器） │  最少、最慢、最接近真实
        ├─────────────────────┤
        │ 宿主侧集成（wasmtime）│  验证 ABI、内存、导入导出
        ├─────────────────────┤
        │ 边界测试（wasm-bindgen-test）│ 验证 JS ↔ WASM 转换
        ├─────────────────────┤
        │ 纯逻辑单元测试（cargo test）│  最多、最快、无 WASM
        └─────────────────────┘
原则：能下沉到下一层的，绝不上移。越往上，越慢越脆。

常见误区：把所有测试都写成 headless 浏览器测试。
后果：CI 从 30 秒变成 10 分钟，失败原因还难定位。
正确做法：逻辑测在 Rust 层，只有必须验证「浏览器行为」的才上端到端。

use wasm_bindgen_test::*;

wasm_bindgen_test_configure!(run_in_browser);

#[wasm_bindgen_test]
fn test_add() {
    assert_eq!(my_crate::add(2, 3), 5);
}

#[wasm_bindgen_test]
async fn test_fetch_roundtrip() {
    let val = my_crate::fetch_value().await.unwrap();
    assert!(val > 0.0);
}

# 在 Node 环境跑（快，但无 DOM）
wasm-pack test --node

# 在 headless Chrome 里跑（有 DOM，最接近真实）
wasm-pack test --headless --chrome

# 在 headless Firefox 里跑
wasm-pack test --headless --firefox

wasm-bindgen-test 测的是「模块内部」，但生产事故多发生在「宿主与模块的边界」：
  import 函数缺失或签名不符
  内存所有权约定被违反（悬垂指针、重复释放）
  ABI 结构体布局与宿主预期不一致
这些必须在宿主侧、用真实运行时验证 —— wasmtime 是首选。

use wasmtime::*;

#[test]
fn test_plugin_abi() -> anyhow::Result<()> {
    let engine = Engine::default();
    let module = Module::from_file(&engine, "target/plugin.wasm")?;
    let mut store = Store::new(&engine, ());
    let instance = Instance::new(&mut store, &module, &[])?;

    // 1. 验证导出的入口存在且签名正确
    let alloc = instance.get_typed_func::<i32, i32>(&mut store, "alloc")?;
    let handle = instance.get_typed_func::<(i32, i32), i32>(&mut store, "handle")?;

    // 2. 验证 ABI 往返：写入 → 调用 → 读回
    let ptr = alloc.call(&mut store, 16)?;
    let memory = instance.get_memory(&mut store, "memory").unwrap();
    memory.write(&mut store, ptr as usize, &[1u8; 16])?;
    let rc = handle.call(&mut store, (ptr, 16))?;
    assert_eq!(rc, 0);

    // 3. 验证内存上限被尊重（越界应 trap）
    let limits = StoreLimitsBuilder::new().memory_size(1 << 20).build();
    Ok(())
}

宿主侧测试的三类断言：
  结构断言  导出/导入函数齐全，签名匹配（get_typed_func 会校验）
  行为断言  给定输入得到预期输出（ABI 往返）
  约束断言  越界、超限、非法调用必须 trap 而非静默通过

契约测试的对象是「宿主与插件之间的接口」，而非实现：
  输入：一组规范化的请求（JSON / 二进制）
  输出：期望的响应（或响应约束）
  断言：响应必须满足契约（字段齐全、类型正确、范围合法）
用途：插件升级、ABI 演进时，用它守住「不破坏既有调用方」。

// 契约用黄金文件驱动，宿主与插件共用同一份期望
#[test]
fn test_contract_golden() -> anyhow::Result<()> {
    for case in load_cases("tests/golden/*.json")? {
        let out = run_plugin(&case.input)?;
        assert_eq!(out, case.expected, "case {}", case.name);
    }
    Ok(())
}

黄金数据的四条纪律：
  1. 与代码一起进版本库，变更必须走评审（它是「事实来源」）
  2. 用确定性输入：禁用随机数、时间、并行顺序不确定的输出
  3. 覆盖边界：空输入、极值、最大长度、非法字符
  4. 提供「一键重生成」脚本，但重生成必须人审差异

WASM 的典型不可信输入：
  用户上传的 wasm 模块（插件市场）
  外部传入的二进制数据（解析器、解码器）
  任意字节流（协议解析、格式转换）
模糊测试的作用：用海量畸形输入，找出「本不该通过却通过」或「直接崩溃」的路径。

// fuzz_targets/gen_module.rs：随机生成合法但奇怪的 wasm 模块
#![no_main]
use libfuzzer_sys::fuzz_target;

fuzz_target!(|data: &[u8]| {
    let mut cfg = wasm_smith::Config::default();
    cfg.max_memories = 2;
    if let Ok(module) = wasm_smith::Module::new(data, cfg) {
        let bytes = module.to_bytes();
        // 交给宿主加载：必须要么正确执行，要么被干净拒绝，绝不 panic
        let _ = my_host::validate_and_run(&bytes);
    }
});

断言什么：
  不 panic    宿主绝不能因畸形输入而崩溃（Rust 侧用 catch_unwind 兜底）
  不越界      trap 必须是受控的，不能污染宿主内存
  资源可控    内存与执行步数必须有上限，防「合法但巨耗资源」的输入
运行：cargo fuzz run gen_module -- -max_total_time=300

差分测试：同一份输入，喂给两个实现，断言输出一致。
常见对照组合：
  WASM 版 vs 原生版（同一份 Rust 代码，两种目标）
  WASM 版 vs 参考实现（Python / JS 的朴素实现）
  优化前 vs 优化后（回归验证）
价值：把「正确性」从「人写期望值」变成「两个独立实现互证」。

#[test]
fn test_differential_wasm_vs_native() {
    for input in generate_inputs(1000) {
        let native = native_impl(&input);      // 原生编译的目标
        let wasm = run_in_wasmtime(&input);    // WASM 目标
        assert_eq!(native, wasm, "input={:?}", input);
    }
}

差分测试的三个坑：
  1. 浮点：WASM 与原生在 NaN 传播、fma 上可能有细微差异 → 用容差比较
  2. 迭代顺序：HashMap 遍历顺序不确定 → 输出前排序
  3. 未定义行为：原生 UB 可能给出「看似正确」的结果，WASM 更确定
对策：能确定化的一律确定化，不能的用容差或规范化输出。

三层覆盖率的采集工具：
  Rust 源码覆盖   cargo-llvm-cov（源码级，编译到 WASM 前就能采）
  WASM 指令覆盖   LLVM 的 source-based coverage + wasm 插桩
  JS 侧覆盖       headless 浏览器 + coverage API（测胶水代码）
实践：以「源码级覆盖率」为主，因为它直接对应可读代码，
      WASM 指令级覆盖率用于确认「编译后没有意外丢弃的路径」。

# Rust 源码覆盖率（在测试目标上）
cargo llvm-cov --target wasm32-unknown-unknown --html

# 只看核心 crate，排除生成代码与第三方
cargo llvm-cov --ignore-filename-regex 'tests/|target/'

CI 四阶段（快 → 慢，失败即停）：
  1. cargo test            纯逻辑，秒级
  2. wasm-pack test --node 边界，秒级
  3. 宿主侧 wasmtime 测试   集成，秒级
  4. headless 浏览器 + 模糊冒烟  端到端，十秒级
另设「夜间任务」跑长时间模糊测试与跨浏览器矩阵。

# .github/workflows/wasm-ci.yml（节选）
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: rustup target add wasm32-unknown-unknown
      - run: cargo test --workspace
      - run: wasm-pack test --node
      - run: cargo test -p host-integration
      - run: wasm-pack test --headless --chrome

CI 优化：
  [ ] 缓存 cargo registry 与 target 目录，避免每次重编
  [ ] 用 sccache 跨 job 共享编译产物
  [ ] 模糊测试设固定时间预算（如 60 秒冒烟），避免拖长流水线
门禁：
  [ ] 覆盖率低于阈值阻断合并
  [ ] 性能回归超阈值阻断合并（见第 9 章）
  [ ] 黄金数据变更必须人工 review

WASM 性能回归要分三类度量：
  编译时间    模块从字节到可执行（见流式编译专题）
  冷启动      实例化 + init 钩子
  稳态吞吐    热路径的每调用耗时
三者变化的诱因不同，必须分开记录，否则会互相掩盖。

[ ] 四层测试齐备，能下沉的绝不上移
[ ] ABI 与内存约定有宿主侧断言（含越界 trap 验证）
[ ] 契约用黄金文件驱动，重生成必人审 diff
[ ] 不可信输入走 wasm-smith 模糊测试，断言不 panic / 不越界
[ ] 移植场景加差分测试，注意浮点容差与迭代顺序
[ ] 覆盖率以源码级为主，纳入门禁但设合理阈值
[ ] CI 四阶段快慢排序，长时任务放夜间
[ ] 性能回归分三类度量，固定硬件上跑