使用Testim进行Javascript端到端测试：示例介绍

This post is an introductory guide to JavaScript end-to-end testing, using a tool called Testim. End-to-end testing (or E2E Testing, for short) is one of the many types of automated tests that currently exist for web applications. This type of testing occupies a somewhat peculiar place in the whole automated testing scenario. While it’s arguably one of the most important types of testing, it’s also one of the most misunderstood. Due to that, it’s not used as much as it should be. And that results in developers and software organizations missing out on the benefits it can provide.

这篇文章是使用称为Testim的工具进行JavaScript端到端测试的入门指南。 端到端测试（简称E2E测试）是当前针对Web应用程序存在的多种自动化测试之一。 在整个自动化测试方案中，这种类型的测试占据了一些特殊的位置。 尽管它可以说是最重要的测试类型之一，但它也是最容易被误解的一种。 因此，它没有得到应有的使用。 这就导致开发人员和软件组织错过了它可以提供的好处。

This post is an attempt to solve that problem. We’ll offer an introductory tutorial to end-to-end testing in JavaScript applications, using Testim as the example tool. We’ll begin by quickly defining end-to-end testing so that you can understand its place in a complete testing strategy.

这篇文章是试图解决该问题的尝试。 我们将使用Testim作为示例工具，为JavaScript应用程序中的端到端测试提供入门教程。 我们将从快速定义端到端测试开始，以便您可以了解其在完整测试策略中的位置。

With that out of the way, we’ll proceed to the practical part of the post. We’ll use the Google Calculator app as an example, so we can perform E2E on it using Testim. Let’s begin.

顺便说一句，我们将继续该帖子的实际部分。 我们将以Google计算器应用为例，以便我们可以使用Testim在其上进行E2E。 让我们开始。

端到端测试简介 ( A Brief Introduction to End-to-End Testing )

Also called functional testing, end-to-end testing occupies a peculiar and probably non-enviable position in the whole automated testing scenario. Before we’re able to understand said peculiarity, let’s first define E2E testing.

端到端测试在整个自动化测试场景中也被称为功能测试，在特殊且可能不令人羡慕的位置。 在我们能够理解上述特性之前，让我们首先定义端到端测试。

定义端到端测试 (Defining End-to-End Testing)

End-to-end testing is a type of testing that exercises the whole application, from one end (the UI) to the other (the backend and database) to verify whether it behaves as expected. In other words, end-to-end testing, unlike other types of testing such as unit tests, is expected to fully engage external dependencies, such as the database and the filesystem—because the very integrations with those systems should be tested at some point.

端到端测试是一种测试，它对整个应用程序进行测试，从一端（UI）到另一端（后端和数据库），以验证其行为是否符合预期。 换句话说，与其他类型的测试（例如单元测试）不同，端到端测试有望完全利用外部依赖关系，例如数据库和文件系统，因为与这些系统的高度集成应该在某个时刻进行测试。

End-to-end testing, then, is a form of black-box testing. It’s not concerned with any implementation details of the application it’s testing, but only with how it behaves externally.

端至端的测试，那么，是一种形式的黑箱测试 。 它与正在测试的应用程序的任何实现细节无关，而仅与它在外部的行为方式有关。

E2E tests the application in a way that closely resembles a real user interacting with it. One could argue that E2E testing is the most realistic type of automated test. Because of that, it might be able to detect problems that the other forms of testing cannot, which makes it a crucial type of testing.

E2E以非常类似于真实用户与其交互的方式来测试应用程序。 有人可能会说E2E测试是最现实的自动化测试类型。 因此，它可能能够检测其他形式的测试无法解决的问题，这使其成为一种至关重要的测试类型。

端到端测试的挑战 (The Challenges of End-to-End Testing)

The only thing that can compete with the importance of end-to-end testing is the seemingly universal dislike it suffers.

唯一可以与端到端测试的重要性相抗衡的是它似乎遭受的普遍不满。

E2E tests, when not done correctly, cause issues instead of solving them. They can be hard to create, slow to run, and easy to break, even due to the smallest changes to the codebase. A suite of poorly managed end-to-end tests quickly becomes a maintenance nightmare. It doesn’t take long until the team decides they’re just not worth the effort and stop creating the tests altogether.

如果未正确完成E2E测试，则会导致问题而不是解决问题。 即使对代码库进行了最小的更改，它们也很难创建，运行缓慢且易于破坏。 一套管理不善的端到端测试Swift成为维护的噩梦。 不久之后，团队就认为他们不值得付出努力并完全停止创建测试。

Why is end-to-end testing susceptible to these problems? It’s mostly a matter of relying too much on UI details that change a lot, such as names and positions of UI components. When E2E testing tools produce tests that are tightly coupled to these details, the tests are bound to fail often and easily.

为什么端到端测试容易受到这些问题的影响？ 主要是过分依赖于变化很大的UI详细信息（例如UI组件的名称和位置）的问题。 当端到端测试工具生成与这些细节紧密相关的测试时，这些测试注定会经常且容易失败。

是时候卷起袖子了：Testim入门 ( Time to Roll up Your Sleeves: Getting Started With Testim )

Now it’s time to show you how to get started with Testim so you can see what automated UI testing looks like.

现在该向您展示如何开始使用Testim，以便您看到自动UI测试的外观。

第一步：创建帐户并安装Testim浏览器扩展 (First Steps: Creating an Account and Installing the Testim Browser Extension)

Go to https://testim.io, and click on “Start Trial.” You’ll see a message asking you to create an account. You can either choose the quick signup with Google or GitHub or create a new account by providing a business e-mail address and creating a password.

转到https://testim.io ，然后单击“开始试用”。 您会看到一条消息，要求您创建一个帐户。 您可以选择通过Google或GitHub快速注册，也可以通过提供公司电子邮件地址并创建密码来创建新帐户。

After creating your account and logging in, you’re going to see this:

创建帐户并登录后，您将看到以下内容：

Click on “Create test” and you’ll be asked to install the Testim extension for the Chrome browser:

点击“创建测试”，系统会要求您为Chrome浏览器安装Testim扩展程序：

Is the extension installed? Good. Now you have all you need to start performing end-to-end testing with Testim.

是否安装了扩展程序？ 好。 现在，您拥有开始使用Testim进行端到端测试所需的一切。

使用Testim创建您的第一个测试 (Creating Your First Test With Testim)

On Chrome, go to the address bar, type “calculator” and hit enter. You should see this:

在Chrome上，转到地址栏，输入“ calculator”，然后按Enter。 您应该看到以下内容：

We’ll now create a test for the “+” button. To do that, click on the Testim extension’s icon, as you can see in the following image:

现在，我们将为“ +”按钮创建一个测试。 为此，请单击Testim扩展程序的图标，如下图所示：

That will open the following menu:

Now, click on “CREATE AUTOMATED TEST.” Doing so will open Testim and attach the current tab to it. Then, go back to the calculator tab. There, you’ll see this:

现在，单击“创建自动测试”。 这样做将打开Testim并将当前选项卡附加到它。 然后，返回到计算器选项卡。 在那里，您将看到：

Now just use the application as you would normally do, and Testim will record your actions. We’ll create a test that verifies the “2 + 2” sum works as intended. Just perform the operation normally and, as soon as you’re done, go back to Testim, which should look like this:

现在只需像平常一样使用该应用程序，Testim就会记录您的操作。 我们将创建一个测试，以验证“ 2 + 2”总和是否符合预期。 只需正常执行该操作，完成后立即返回Testim，它应如下所示：

Click on “SAVE” and, when asked, enter a name and description for your test:

单击“保存”，并在询问时输入测试的名称和说明：

运行测试 (Running Your Test)

Let’s run your recently created test. Click on the “Automate” button, located on Testim’s left panel:

让我们运行您最近创建的测试。 单击Testim左侧面板上的“自动化”按钮：

You’ll see a test list containing only your newly created test:

您将看到一个仅包含新创建的测试的测试列表：

Select the test, click on its “play” button, and it will run.

选择测试，单击其“播放”按钮，它将运行。

After clicking on the button, you’ll be warned not to touch the mouse and keyboard while the tests run:

单击按钮后，将警告您在运行测试时不要触摸鼠标和键盘：

Click on “OK.” The test will be run in a new Chrome tab, executing exactly what you’ve recorded. After the test finishes, the window will be closed. If you go back to the Testim tab, you should see the test’s result:

点击“确定”。 该测试将在新的Chrome标签中运行，完全执行您所记录的内容。 测试完成后，该窗口将关闭。 如果返回“ Testim”选项卡，则应该看到测试结果：

Good news—you’ve just run your first Testim test. Bad news: it didn’t really test anything. Let’s see why and how to fix it.

好消息-您刚刚运行了第一个Testim测试。 坏消息：它并没有真正测试任何东西。 让我们看看为什么以及如何修复它。

添加验证 (Adding a Verification)

The test you’ve just created lacks a verification. In other words, the test must verify whether two plus two is really four. Without that, it doesn’t test anything.

您刚创建的测试没有验证。 换句话说，测试必须验证两个加二是否真的是四个。 没有它，它不会测试任何东西。

Click on the “Automate” button again, which will take you back to the test listing. Click on the test name so you can edit it:

再次单击“自动”按钮，这将带您回到测试列表。 单击测试名称，以便您可以对其进行编辑：

Our test has six steps. We’re now adding an additional step—the validation. Click on the button with the “plus” sign, located just after the last step. This is what you’re going to see:

我们的测试有六个步骤。 现在，我们添加了另一个步骤-验证。 单击最后一步之后的带有“加号”的按钮。 这是您将看到的：

Click on the “Validations” option (the one with the check sign), and you’ll see this:

单击“验证”选项（带有复选标记的选项），您将看到以下内容：

Then, click on “Validate element text.” You’ll be taken back to the calculator, where you should click on the result field:

然后，点击“验证元素文字”。 您将被带回计算器，您应该在其中单击结果字段：

Going back to Testim, you’ll see that the test has an extra step now:

回到Testim，您将看到测试现在还有一个额外的步骤：

Hover over the new step and click on the engine icon to show the properties:

将鼠标悬停在新步骤上，然后单击引擎图标以显示属性：

Now it’s just a matter of editing the “Expected value” field, setting it to ‘4’. After doing that, click on the “SAVE” button again. You’ll see a box prompting you for a message explaining your change. Type “Add validation step” and click on OK:

现在，只需编辑“期望值”字段，并将其设置为“ 4”即可。 完成后，再次单击“保存”按钮。 您会看到一个框，提示您输入消息以说明您的更改。 输入“添加验证步骤”，然后单击“确定”：

Now you to have set the “Expected value” field to 4 and then click on “SAVE” again. When you’re prompted for a message, enter the “Add validation step.”

现在，您已经将“期望值”字段设置为4，然后再次单击“保存”。 当系统提示您输入消息时，请输入“添加验证步骤”。

We’re done adding a validation phase to our test. If we run it again, it will still pass. But this time, it’s going to be doing something useful, thanks to the verification step we’ve just added to it.

我们已经在测试中添加了验证阶段。 如果我们再次运行它，它仍然会通过。 但是这次，由于我们刚刚添加了验证步骤，它将会做一些有用的事情。

结论 ( Conclusion )

End-to-end testing is incredibly important for web applications. It’s the type of testing that most closely resembles an actual user interacting with the application. Besides that, E2E testing deliberately engages with external dependencies. So, end-to-end testing is able to detect problems that other types of testing usually don’t detect,

端到端测试对于Web应用程序非常重要。 这是最类似于实际用户与应用程序交互的测试类型。 除此之外，端到端测试故意与外部依赖项联系在一起。 因此，端到端测试能够检测到其他类型的测试通常无法检测到的问题，

Unfortunately, E2E testing gets a bad rap. That’s due to issues being caused by traditional testing tools that rely too much on volatile implementation details on interfaces.

不幸的是，端到端测试失败了。 这是由于传统测试工具所引起的问题，这些工具过于依赖接口上易变的实现细节。

This post tried to remedy E2E’s reputation. It covered the definitions of this type of testing and finished with an example of end-to-end testing using Testim, which is a tool that employs AI to create test suites that are robust, reliable and self-healing.

这篇文章试图纠正E2E的声誉。 它涵盖了此类测试的定义，并以使用Testim进行端到端测试的示例结尾，后者是一种利用AI创建强大，可靠和自我修复的测试套件的工具。

翻译自: https://scotch.io/tutorials/javascript-end-to-end-testing-with-testim-intro-with-examples