Checkly Community最近聚在一起谈论剧作家in our public Slack！我的剧作家大使John Hill和我邀请所有人提出问题并分享有关微软端到端测试工具的提示。
，有很多！让我们看看我最喜欢的问题（和学习）来自社区！您准备好准备一袋剧作家的技巧了吗？让我走！
您应该如何处理端到端测试中的并行性？
通常，最好的做法是尽可能多地进行测试，以免看到您的测试时间穿过屋顶。没有人喜欢等待三十分钟的绿色部署光， 一个永久（或片状）的测试套件是您的测试工作失败。
的主要原因。但是，在软件开发方面，事情都很复杂，每个复杂的项目在测试方面都面临着自己的挑战。
一个棘手的情况是涉及资源更新的测试用例。如果您的所有测试并行进行，那么很容易发现一个测试可以创建或删除资源的种族条件，而另一项测试也在测试它！这个问题很难解决，没有理想的解决方案，但是our CTO Tim Nolet共享了一种可能的方法：
对于不依赖数据库中状态的非破坏性测试，Tim建议全力进行并行测试。您的测试用例可能包括检查在单击按钮后弹出的模态或当有人与文本字段互动时呈现的预览。所有这些测试都可以独立运行并并行运行。
有了陈述测试，这是一个不同的故事。如果资源创建和更新正在发挥作用，则有时不可避免地运行测试以避免一个测试与另一个测试混乱。
但是如何在剧作家项目中分开并运行这些不同的测试？
要在您的项目中实施Tim的建议，您必须熟悉剧作家如何处理并行性。
通常，剧作家并行运行不同的测试文件，并且文件中的所有测试均顺序运行。但是请注意，fullyParallel Global配置会改变此行为，并并行运行每个测试案例，无论其定义在哪里。
默认行为使您可以运行单个文件顺序中的测试。例如，如果要创建，更新和删除另一个文件，则在单个文件中进行测试保证执行订单。
这是一个很好的开始，但不幸的是，它不能保证其他规格文件会干扰类似的资源，这再次可能导致误报。幸运的是，剧作家是高度可配置的，您可以通过定义运行测试的工人数量通过the CLI or Playwright config禁用并行性。
npx playwright test --workers=1
全局workers配置使您可以使用不同的并行化设置运行测试。独立和无状态测试可以完全平行地进行，而顺序依赖性测试可以按顺序进行。
拆分测试，leverage custom annotations或文件路径约定，以完全并行或顺序模式运行剧作家。下面的package.json示例利用不同的目录将平行于顺序测试用例分开。
{
"name": "parallel",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test:parallel": "npx playwright test tests/parallel/",
"test:sequence": "npx playwright test tests/sequence/ --workers=1"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"@playwright/test": "^1.29.2"
}
}
使用此设置，您可以在不遇到测试冲突的情况下运行npm run test:parallel和npm run:sequence。通过分开无状态和陈述测试，您将能够减少测试碰撞并尽快进行独立测试。
但是，与相同资源相互作用的端到端测试只是片状的原因之一。还有很多其他！
片状测试的常见原因是什么？如何避免进行测试？
进行片状测试的原因很多。我们的客户解决方案负责人Giovanni Rago分享了他的顶级片状罪犯。
正如GIO所述，次优的等待是UI和端到端测试中的一个常见问题。
要测试您的应用程序必须达到特定状态，可能需要加载JavaScript或必须解决潜在的API调用。测试UIS有多种方法。
但是，在进入明确等待的方案之前，请确保检查剧作家的auto-waiting mechanisms和web-first assertions。有了所有内置的自动等待机制，您很少需要担心明确的等待。例如，如果您想测试包括最终变得可见的组件的UI流，则诸如click之类的剧作家动作等待元素变得可见。
这些功能使您能够使用看起来同步的代码高度测试异步UI。
// Playwright retries to click this button until it works or times out
await page.getByRole('button').click();
但是，正如Gio所说，有时这些内置的等待机制足够了，您必须等待明确的事件发生或达到UI状态。约翰·希尔（John Hill）将事情提升到了另一个层次，并建议观看特定的网络请求，以使功能确定性。
如果单击一个按钮，则触发API调用，可以等待API调用以解决并测试UI是否反应。
正如约翰所说：
如果您的浏览器具有HTTP API后端，则将确定性添加到您的测试中的＃1方法是等待特定的网络请求以解决。
测试片状前端应用程序时，我经历的薄片中有99％来自片状和不可靠的后端。
前端测试只是坏消息的承载。
如果您想检查此方法的示例，here’s the code John and the team at Open MCT run to test UIs request-dependent at Nasa。
如何模拟剧作家中的自定义键盘交互？
如果您正在使用SaaS产品并瞄准Stellar UX，则可以实现键盘快捷键和交互。这些可能具有挑战性的测试，但幸运的是，剧作家还支持一种控制虚拟键盘的方法。
Playwright’s keyboard functionality enables you to interact with input elements and pages像真实的用户一样。
await page.keyboard.press("Meta+KeyA")
await page.keyboard.type('This is a line of text\n');
此功能非常适合快捷方式，但对于高度定制和复杂的组件也很有价值。一个示例是基于JS的代码编辑器，例如摩纳哥。
数百万开发人员使用摩纳哥，因为它内置在VS代码中（以及App.Checklyhq.comð）。但是，它如何在引擎盖下工作，如果它嵌入了您的应用程序中，您将如何测试自定义编辑器？
Open the Monaco Playground查看Microsoft的开源编辑器组件。当您检查编辑器时，您会发现要提供语法突出显示，编辑器组件上都有divs和跨度。但是，如何编辑和测试这些并与编辑互动？
摩纳哥和其他代码编辑器组件通常包含隐藏或透明的文本方面，以捕获键盘事件并使事情更容易访问。捕获了Textarea击键，帆布元素呈现代码建议，并且跨度/divs显示突出显示的代码。涉及很多魔术，测试非常具有挑战性。
幸运的是，剧作家的虚拟键盘在这里和剧作家核心团队成员马克斯·施密特（Max Schmitt）分享了koude6 is at your service to interact with Monaco。
await page.goto('https://microsoft.github.io/monaco-editor/playground.html');
const monacoEditor = page.locator(".monaco-editor").nth(0);
await monacoEditor.click();
await page.keyboard.press("Meta+KeyA");
await page.keyboard.type('This is a line of text\n');
await page.screenshot({ path: example.png });
此功能允许测试和模拟键盘交互，而不是用字符串值填充输入。按特定的键组合，跳到一条线的开头，或者删除三次删除键！您可以模仿用户的键盘行为！
真正的用户是不可预测的。您如何保证您的应用程序在端到端测试中攻击时不会破坏？
如何在长端到端的测试流中捕获JavaScript错误？
当用户与之交互时，监视您的应用程序是否会引发JavaScript异常。幸运的是，通过利用诸如pageerror之类的发射页面事件，对JavaScript错误的反应在剧作家中很简单。用几行代码进行反应和计数异常。
// Log all uncaught errors to the terminal
page.on('pageerror', exception => {
console.log(`Uncaught exception: "${exception}"`);
});
- 相关视频：如果您想学习这些工作方式，have a look at one of our Playwright tips on YouTube。
约翰·希尔（John Hill）再次将事情置于新的水平，并分享了they implement JavaScript error tracking with Playwright fixtures的方式。他的方法使您可以收集所有JS错误，直到测试结束，然后才使其失败。
exports.test = base.test.extend({
failOnConsoleError: [true, { option: true }],
/**
* Extends the base page class to enable console log error detection.
* @see {@link https://github.com/microsoft/playwright/discussions/11690 Github Discussion}
*/
page: async ({ page, failOnConsoleError }, use) => {
// Capture any console errors during test execution
const messages = [];
page.on('console', (msg) => messages.push(msg));
await use(page);
// Assert against console errors during teardown
if (failOnConsoleError) {
messages.forEach(
msg => expect.soft(msg.type(), `Console error detected: ${_consoleMessageToString(msg)}`).not.toEqual('error')
);
}
}
});
示例利用固定装置和软主张，如果您感到好奇，请看一下John’s provided example code。
结论
这些是我从社区AMA会议上学习的我最喜欢的剧作家，我仍然惊讶于端到端测试的到来。如果您想继续学习剧作家，check out our Checkly YouTube channel，当我发现它们时，我在这里分享所有这些细致的技巧。如果您有任何疑问，don’t hesitate to drop into Slack, I’m happy to help！
最后，您可能知道测试只是运输恒星产品的开始。如果您想开始监视您的应用程序，并确信您的网站始终运行，这就是我们在Checkly上所做的。 Sign up and run Playwright tests at any time from around the world。它是免费的，非常酷，相信我！ ð