测试从 0 到 1 · 一个人做项目怎么建立可信度

诚实是这套体系的起点。不装、不绕、不拿「AI 说它测过了」当证据。下面是实测数字。

讲测试为什么重要，最好的教材不是「覆盖率」，是你自己线上出过的那一次。delimao-system 的 collections 表就是活教材。

事故现场 reconstruction（基于真实表结构）

同一个 bug，有测试的版本会怎样

一个人做项目，没有同事帮你 review、没有 QA，所以「哪些必须测」这个问题比「怎么测」重要得多。测错地方，测试会变成负担，然后你就停掉了。

不需要装任何东西。Node 18+ 自带 node:test 和 node:assert，TypeScript 用 tsx 跑就行（你项目里本来就在用 tsx watch）。

① 写一个测试文件（engine 层）

// packages/engine/test/price.test.ts
import { test } from 'node:test'
import assert from 'node:assert/strict'
import { parseModelNo, calcPrice } from '../src/price.js'

// 用例 1：真实型号能解析出关键字段（正向）
test('DL-2409-1 能解析出系列和宽度', () => {
  const r = parseModelNo('DL-2409-1')
  assert.equal(r.series, 'DL')
  assert.equal(r.width, 2409)
})

// 用例 2：非法型号必须抛错，不能返回垃圾（负向 —— 见第 07 节）
test('乱写的型号必须抛错', () => {
  assert.throws(() => parseModelNo('乱写的型号'))
})

// 用例 3：无尺寸必须「算不了」，不能返回 0 元（这是钱的问题）
test('缺尺寸的订单必须报算不了，不能返回 0 元', () => {
  const r = calcPrice({ modelNo: 'DL-2409-1', width: null, height: null })
  assert.equal(r.ok, false)
  assert.equal(r.amount, null)      // ← 注意是 null，不是 0
  assert.match(r.reason, /尺寸/)     // ← 要说清楚缺的是哪一个
})

// 用例 4：正向算价（一个手工算过的值，必须写死在用例里）
test('DL-2409-1 + 1200×800 报价等于预期值', () => {
  const r = calcPrice({ modelNo: 'DL-2409-1', width: 1200, height: 800 })
  assert.equal(r.ok, true)
  assert.equal(r.amount, 3186.40)   // ← 这个值必须是手工算过的，不能是跑出来的
})

② 挂载命令（加到 package.json 的 scripts）

// packages/engine/package.json
{
  "scripts": {
    "test": "tsx --test test/*.test.ts",
    "engine:test": "tsx --test test/*.test.ts"
  }
}

// delimao-system 根 package.json（workspaces）
{
  "scripts": {
    "test": "npm run test -w @delimao/engine"
  }
}

③ 一条「改坏了它真的会红」的验证

你的库是 SQLite + better-sqlite3（26 处）+ WAL。在这种环境里造测试数据最快的方式是直接建一个临时 db 文件——不要为了测试起 Docker、不要起内存版、更不要 mock 掉整个 db 层。

① 一个 20 行的测试库工厂（每个测试文件复用）

// tests/helpers/makeDb.ts
import { mkdtempSync, rmSync } from 'node:fs'
import { tmpdir } from 'node:os'
import { join } from 'node:path'
import Database from 'better-sqlite3'

/** 建一个一次性测试库：用完即删，不碰任何真实数据 */
export function makeTestDb() {
  const dir = mkdtempSync(join(tmpdir(), 'delimao-test-'))
  const db = new Database(join(dir, 'test.db'))
  db.pragma('journal_mode = WAL')          // 和线上一致，才能测出 WAL 相关行为
  db.exec(`
    CREATE TABLE models  (no TEXT PRIMARY KEY, list_price REAL NOT NULL);
    CREATE TABLE orders  (id INTEGER PRIMARY KEY, no TEXT, payload TEXT NOT NULL);
    CREATE TABLE order_items (id INTEGER PRIMARY KEY, order_id INTEGER, qty INTEGER);
  `)
  return {
    db,
    close() { db.close(); rmSync(dir, { recursive: true, force: true }) }
  }
}

② 用 beforeEach / afterEach 保证用例之间不互相污染

// packages/engine/test/collections.test.ts
import { test, beforeEach, afterEach } from 'node:test'
import assert from 'node:assert/strict'
import { makeTestDb } from '../../../tests/helpers/makeDb.js'

let h: ReturnType<typeof makeTestDb>

beforeEach(() => { h = makeTestDb() })   // 每个用例都拿一个全新空库
afterEach(()  => h.close())              // 用完删掉

test('表单行写入后能原样读回（JSON blob 回归）', () => {
  h.db.prepare('INSERT INTO orders (no, payload) VALUES (?, ?)')
    .run('A001', JSON.stringify({ glass: '8mm', w: 1200, qty: 2 }))
  const row = h.db.prepare('SELECT payload FROM orders WHERE no = ?').get('A001') as any
  assert.deepEqual(JSON.parse(row.payload), { glass: '8mm', w: 1200, qty: 2 })
})

test('写坏的 payload 必须被挡住，不能静默写进库', () => {
  // 这条用例是第 02 节那次崩库的直接回归
  assert.throws(() => {
    h.db.prepare('INSERT INTO orders (no, payload) VALUES (?, ?)').run('A002', '{"items":[')
  })
  const n = h.db.prepare('SELECT COUNT(*) AS c FROM orders').get() as any
  assert.equal(n.c, 0)   // ← 关键断言：坏数据根本没进去
})

③ 迁移脚本单独测：在临时库上「从零跑一遍」

// tests/migrate.test.ts —— 迁移只跑一次，跑错不可逆，所以必须测
import { test } from 'node:test'
import assert from 'node:assert/strict'
import { makeTestDb } from './helpers/makeDb.js'

test('migrate:baseline 能在空库上从零建齐全部表', () => {
  const { db, close } = makeTestDb()
  try {
    runAllMigrations(db)                       // 把 packages/db 的迁移按顺序喂进去
    const tables = db.prepare(
      "SELECT name FROM sqlite_master WHERE type='table' AND name NOT LIKE 'sqlite_%'"
    ).all() as any[]
    assert.equal(tables.length, 27)            // ← 27 张表，一个都不能少
    assert.ok(tables.some(t => t.name === 'collections'))
  } finally {
    close()
  }
})

test('migrate:add_column 在已有数据上升级不丢行', () => {
  const { db, close } = makeTestDb()
  try {
    db.exec('CREATE TABLE orders (id INTEGER PRIMARY KEY, no TEXT)')
    db.prepare('INSERT INTO orders (no) VALUES (?)').run('OLD01')
    runAllMigrations(db)
    const n = db.prepare('SELECT COUNT(*) AS c FROM orders').get() as any
    assert.equal(n.c, 1)                       // ← 加字段不能把老数据清掉
  } finally {
    close()
  }
})

这是零售 × AI 落地工程师这个身份特有的测试难点，也是最容易漏的一类。
一般软件里，「无数据」「失败」是异常路径；在零售单据里，「算不了」是常态——生产 400 单里 97% 无尺寸，意味着「无尺寸输入」是全系统出现频率最高的输入，而不是边角料。

为什么这一层特别容易没测试

负向用例该怎么写（4 类断言，缺一不可）

// ① 「缺东西」必须明确报错，且说清缺什么
test('缺 width 时明确报尺寸缺失', () => {
  const r = calcPrice({ modelNo: 'DL-2409-1', width: null, height: 800 })
  assert.equal(r.ok, false)
  assert.match(r.reason, /width/)       // ← 必须点名缺的是 width，不能只说「参数有误」
})

// ② 关键：失败时金额是 null，不是 0（0 会被前端当成「免单」）
test('算不了时 amount 必须是 null 而不是 0', () => {
  const r = calcPrice({ modelNo: 'DL-2409-1', width: null, height: null })
  assert.equal(r.amount, null)
  assert.notEqual(r.amount, 0)          // ← 显式排除 0，防止哪天有人改成返回 0
})

// ③ 非法业务值（超出物理极限）必须被拒，不能进下一层
test('宽度 99999mm 这种物理上不存在的必须被拒', () => {
  assert.throws(() => calcPrice({ modelNo: 'DL-2409-1', width: 99999, height: 800 }))
})

// ④ 未知型号必须报错，不能静默按市场价算
test('库里没有的型号必须报错', () => {
  assert.throws(() => calcPrice({ modelNo: 'NO-SUCH-MODEL', width: 1200, height: 800 }))
})

我的判断很直接：一个人的测试不该追求覆盖率，该追求「能挡住上次那个坑」。

第一个月就干这 10 条（按你项目里已确认的事故排）

CI 不是「专业化的标志」，是「多人协作的必需品」。一个人要不要上，看的是「有没有第二个人会动你的代码」。

# 一个人阶段（现在的状态）—— 本地前置，够了
"scripts": {
  "pretest": ...,
  "test": "tsx --test packages/*/test/*.test.ts",
  "prepush": "npm test"
}

# 有第二个人之后的 .github/workflows/test.yml（骨架）
name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test
      # SQLite 是文件库，CI 上直接建临时文件即可，不需要 db 服务

13 个项目、27 张表，不可能一次补完。下面这个顺序是按「我已经付过学费的地方」排的，不是按技术难度排。

后果：bug 被固化成规格，而且它永远绿。对策：所有金额类断言，期望值旁边写一行注释说明「这个值怎么来的」（比如「= 玻璃 8mm 单价 × 面积 + 边框，手工核过」）。

后果：比没有测试更糟——它让你以为安全。对策：第 04 节那三步验证（绿 → 改坏 → 必须红）。另外警惕「跑了 N 个测试全绿但没有一个 assert」的文件。

后果：跑单条通过、一起跑失败；改第一个用例导致第五个红。对策：beforeEach 建新库、afterEach 删掉（第 05 节的写法）。「测试不能单独跑」是必须立刻修的信号。

把纯逻辑硬塞进 Http 处理器里、为了 mock 把函数改成全局单例、给每个函数加 options.__disableCheck 参数——这些都是被测试牵着改生产代码。
正确的方向相反：把「算」的部分抽到纯函数（packages/engine 之所以好测，就是因为它没依赖 Express、没依赖 db），然后测纯函数。
好消息：你项目里 engine 已经是零依赖的纯 TS 了——结构天生可测，不需要为测试改任何东西。

后果：测试污染生产数据，或者干脆连不上就整片红。对策：tests/ 目录永远只用临时文件，一个字节都不许碰线上路径。可以在 makeTestDb() 里加一道保险：路径里必须含 tmpdir，否则直接抛错。