如何编写含合理断言的Puppeteer测试？无断言场景是否合规

嘿，这绝对是从Protractor切换到Puppeteer时会遇到的典型困惑，我来帮你理清楚～

首先明确说：你的这段代码是正常的，而且已经在隐性地完成断言逻辑。

为什么当前代码能验证结果？ #

你用的page.waitFor()方法，本质上是在等待一个条件成立——也就是元素数量从itemsCount变成itemsCount + 1。如果创建操作失败，元素数量没变化，这个waitFor就会超时抛出错误，测试自然会失败。所以它已经在替你验证“创建按钮点击后，对象数量增加”这个核心逻辑了，只是没有用显式的expect语法而已。

为什么和Protractor的习惯不一样？ #

Protractor是为Angular量身打造的，它的同步测试模型让我们习惯用expect来做显式断言；但Puppeteer是完全异步的，很多时候“等待条件满足”本身就承担了验证的职责。不过这并不代表不能加显式断言——反而加了会让测试更友好。

优化建议：添加显式断言提升可读性 #

虽然当前代码能跑通，但如果加上显式的expect，测试的意图会更清晰，尤其是团队协作时，其他开发者能一眼看懂你要验证的结果。比如修改成这样：

const items = await page.$$('.item');
const itemsCount = items.length;
await page.click('#create-btn');
// 等待数量更新
await page.waitFor((c) => document.querySelectorAll('.item').length === c, {}, itemsCount + 1);
// 显式断言最终数量符合预期
const finalItems = await page.$$('.item');
expect(finalItems.length).toBe(itemsCount + 1);

这样做的好处：

• 测试报告里会明确显示断言的结果，而不是只抛出一个模糊的“超时”错误
• 能避免一些极端情况：比如如果有其他操作意外修改了元素数量，waitFor提前满足，但显式断言能进一步确认结果的正确性

总结 #

用waitFor来验证条件是Puppeteer里的常规操作，完全正常；但如果想要测试更清晰、更健壮，补充显式断言是个很好的习惯——毕竟代码的可读性和可维护性，在团队项目里太重要啦～

内容的提问来源于stack exchange，提问作者Petr Averyanov