这是关于使用testcafe进行自动化测试（端到端和集成测试）的博客系列的第三部分。博客系列包括以下几个部分：

在第三部分中，我们将"一起"了解当前的技术诀窍，并使用良好的代码结构和可重用方法进行真正的端到端测试。

我们再次以SAP UI5购物车演示为例。我们希望完全测试"标准"工作流：

请提前在下面的gif中查看自动测试执行的结果。本文中描述的所有代码都在Github中维护。只需克隆存储库并使用前面描述的CLI（testcafe）运行测试即可检查代码。

到目前为止，我们一直在测试文件中直接维护选择器和测试执行。不建议这样做。将选择器视为代码的一部分。如果您对同一页面元素执行多次操作（而且您会！）您将不得不复制选择器，这将导致在维护测试代码时出现问题（简称：始终避免重复代码）。当然，对于一组测试操作（例如维护支付或交付信息）也同样有效。另外这个代码应该被重用。

要启用可以使用页面模型。pragma（它不是真正的testcafe特定的，而是普通的typescript）。从技术上讲，每个组件维护一个typescript文件。在此文件中，您可以收集此组件的活动和选择器。因此，对于新的测试，我们使用以下文件夹结构：

文件夹测试包含所有要执行的测试文件夹页面包含您要处理的所有页面/组件

页面产品演示.ts文件包含一个普通的typescript类，您可以在其中定义选择器和操作。下面的代码片段中显示了一个简化的示例。

在这个简短的代码片段中发生了很多事情–让我们详细看看：

ui5Action是从ui5 testcafe selector utils导入的。这是一个singelton实例类，它允许您访问actions API（例如typeText等），而不必将测试中的"u"对象传递给所有方法。ProductDemo类应该定义应用程序中的所有选择器和操作集。对于整个应用程序，什么是云，我们只有一个页面文件。根据不同的场景，每个应用程序也可以有多个页面文件—这实际上取决于您希望如何构造代码和测试。该类在每页上有一个只读属性（截取的短端代码只包含母版页），大数据产品，它定义母版页所有相关页元素的选择器。当然也可以通过在函数中生成选择器来定义"动态选择器"的节点。这里，它用于根据product-id创建列表条目选择器。异步方法"addToShoppingCart"访问选择器以在搜索字段中维护文本，并单击结果列表中找到的条目。正如您在最后两个说明（键入文本并单击）中所看到的，您可以在多个页面元素上链接操作，大数据培训班，而不必重复锅炉板代码"ui5Action"。

页面模型文件本身从不由testcafe调用（只调用测试）。但是，您可以在测试中使用选择器和函数，如测试文件的以下代码片段所示：

页面模型类是从pages文件夹导入的addToShoppingCart方法在测试中重用navToCartButton选择器在测试点击操作中被重用

如果您有多个测试，您现在可以安全地重用此代码（这减少了应用程序内部发生更改时的维护成本–因为您只需在一个位置调整代码）。请参阅多个测试的示例：

下一个代码片段中显示了一个更复杂的重用示例，我们在其中维护支付信息：

选择器非常相似–对于输入本身，我们使用了一个接口，其中包含要填充的参数（剪接中的缩写）。根据是否传递属性值，字段是否填充。注意，类型选项replace和confirm设置为"true"。这将覆盖一个可能存在的测试，并在输入文本后按回车键。

您可能会问-为什么要这么麻烦？只需输入值。这种结构允许我们实现以下测试代码，首先检查一个无效的信用卡号码，然后用一个正确的号码继续测试：

每个默认testcafe几乎不输出任何东西（只有测试开始和结束）。这在testcafe的ui5插件中得到了增强。在增强版中，testcafe自动记录spool日志中的所有活动（无论是断言还是操作）。

在这个spool输出旁边testcafe本身也可以输出junit/xunit文件。在插件的帮助下，您还可以生成代码覆盖率报告。我将在博客文章的下一部分展示这一点。

有两个主要的JSON配置文件来配置测试执行。

testcafe可以通过文件（）来维护。testcaferc.json文件)和命令行参数（参见testcafe文档）ui5插件可以通过文件（.ui5）进行维护-testcafe.json文件)和环境变量（请参阅即将发布的博客文章）

请参阅testcafe文档以获取所有配置可能性的完整描述。在下面的代码片段中，我正在购买一个我正在使用的典型配置：

the.ui5-testcafe.json文件允许配置大部分代码覆盖率。