Protractor中断言异常的最优性能实现方式是什么？

嘿，这个问题我之前在团队做代码评审时也碰到过！用try/catch来断言异步操作的异常确实容易踩坑，而且不是最优雅高效的方式。咱们一步步来拆解优化方案：

先说说你当前代码的隐患 #

你原来的try/catch写法有个关键漏洞：如果doThing.webBrandLink.click()没有抛出异常，测试会直接通过，但这其实不符合你的预期——你本来期望这个点击操作会失败。原来的代码只有在catch块里才有断言逻辑，要是没进入catch分支，就没有任何失败判断，这会导致测试结果不准确。

最优方案：用Jasmine的expectAsync API #

在Protractor（基于Jasmine框架）里，断言异步函数抛出指定异常的最优性能方式是使用Jasmine原生的expectAsync API。这个API是专门为异步场景设计的，它会自动处理异步函数的resolve/reject状态，比手动写try/catch更高效，也更符合框架的最佳实践。

核心优势 #

• 自动处理两种边界情况：如果函数抛出符合预期的异常，测试通过；如果函数成功执行（没抛异常）或抛出的异常不符合预期，测试直接失败
• 代码更简洁，不需要手动编写try/catch和额外的失败判断逻辑
• 框架原生实现，性能比自定义try/catch更优

修改后的示例代码 #

把你原来的代码改成这样（顺便修正了isPresent的调用错误——它是方法，需要加()）：

it('should be unable to click', async () => {
  await expect(doThing.blockingLayer.isPresent()).toBeTruthy();
  await browser.switchTo().defaultContent();
  await browser.waitForAngularEnabled(false);

  // 断言点击操作抛出包含指定内容的异常
  await expectAsync(doThing.webBrandLink.click())
    .toBeRejectedWith(jasmine.stringMatching('is not clickable'));
});

关于你提到的“元素未找到异常”方案的适配 #

你说的那个侧重异常处理的方案，完全可以用expectAsync来适配成断言指定异常的最优方案。不管是元素不可点击还是未找到，核心都是断言异步操作抛出指定异常，用expectAsync + toBeRejectedWith都能完美解决，而且代码更简洁、性能更好。

比如要断言“元素未找到”的异常，只需要修改匹配的字符串：

await expectAsync(doThing.someNonExistentElement.click())
  .toBeRejectedWith(jasmine.stringMatching('No element found using locator'));

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