js代码测试

打开控制台，代码敲下 console.log(1 + 1)，测试回车，代码看到那个小小的测试 2 跳出来。这就是代码最原始的 JS 代码测试。没有框架，测试没有构建工具，代码连个 HTML 文件都不用建。测试浏览器地址栏里输入 javascript:alert('hi') 也算一种测试，代码虽然现在很多浏览器会把这段直接吞掉。测试

我见过太多人把测试这件事搞复杂了。代码项目初始化第一件事就是测试装 Jest、配 Vitest、代码搭 Cypress，测试配置文件写了三百行，代码跑一个断言要等两分钟。不是说这些工具不好，而是你连 typeof null === 'object' 这种坑都没踩过几回，上重型武器纯属浪费。

真正有效的 JS 测试往往从一行代码开始。比如你想确认 [1,2,3].map(parseInt) 到底返回什么。别猜，别翻文档，直接扔进控制台。结果是 [1, NaN, NaN]。为什么？因为 map 给回调传三个参数：元素、索引、数组本身，而 parseInt 接收两个参数：字符串和基数。第二个参数变成了索引值，parseInt('2', 1) 当然 NaN。这种知识，看十篇文章不如亲手跑一次。

写 HTML 文件测试也行。建个 test.html，里面放个 <script> 标签，写几行代码，双击打开。比如验证事件循环里 setTimeout 和 Promise 的执行顺序：

<script> console.log('A'); setTimeout(() => console.log('B'), 0); Promise.resolve().then(() => console.log('C')); console.log('D'); </script>

控制台输出 A D C B。微任务先于宏任务，这个结论你背一百遍不如自己看一遍。有人会问，那 requestAnimationFrame 呢？加进去，再跑。测试的本质就是不断追问“如果这样呢”，然后动手改一行代码看结果。

工具的选择要看场景。调试一段正则表达式，用 regex101.com 比在编辑器里来回改快得多。验证一个算法的时间复杂度，Chrome DevTools 的 Performance 面板录一下，比写 benchmark 脚本直观。但如果你要测的是“用户点击按钮后表单是否提交”，那就得用真浏览器自动化。Puppeteer 或者 Playwright 起一个无头浏览器，模拟点击，断言 URL 变化。这种测试跑一次要几秒，但值得。

有个细节很多人忽略：console.log 打印对象时是引用。你 console.log(obj) 然后修改 obj.a，再展开控制台里那个对象，看到的可能是修改后的值。想抓快照，用 console.log(JSON.parse(JSON.stringify(obj))) 或者 console.table。这个坑我在排查一个状态管理 bug 时踩过，明明打印出来是对的，代码逻辑却走错了分支。后来发现是打印时机和对象引用的问题。

测试异步代码更得小心。async/await 写多了容易忘记 try/catch，一个 rejected promise 没被捕获，在 Node 里直接进程退出。浏览器里倒是安静，但控制台会红一片。我的习惯是，任何 await 外面都包一层 try，哪怕当前觉得不可能出错。测试的时候故意让接口返回 500，看 catch 块能不能接住。

别迷信覆盖率。100% 覆盖率的代码照样有 bug，因为覆盖率只统计行是否执行，不检查逻辑是否正确。我见过一个函数，测试全绿，上线后用户输入空字符串就崩。测试用例里全是 'abc'、'123'，没人试 ''。所以写测试的时候，边界值比正常值重要。数字测 0、-1、Number.MAX_SAFE_INTEGER，字符串测空串、超长串、emoji。

最后说个土办法。遇到诡异 bug，在代码里插满 console.log('---1---')、console.log('---2---')，看哪一段没打印。比断点调试快，尤其在生产环境不方便开 DevTools 的时候。虽然土，但管用。测试这件事，工具是次要的，动手跑起来才是关键。

(责任编辑：焦点)