端到端测试_如何将您的端到端验收测试打包

最新推荐文章于 2024-05-28 14:04:55 发布

cumifi2519

最新推荐文章于 2024-05-28 14:04:55 发布

阅读量413

点赞数

文章标签： python java linux 分布式 docker

原文链接：https://www.freecodecamp.org/news/how-to-dockerize-your-end-to-end-acceptance-tests-dbb593acb8e0/

版权

端到端测试

This article serves as a “how-to” guide for using Selenium Docker images alongside CodeceptJS and an Express server.

本文是将Selenium Docker映像与CodeceptJS和Express服务器一起使用的“操作指南”。

In it, we will cover:

在其中，我们将介绍：

What is E2E acceptance testing?
什么是端到端验收测试？
Why use Docker?
为什么要使用Docker？
Loosely coupled testing tools
松散耦合的测试工具
Layers of testing tools
测试工具层
Creating a test project
创建一个测试项目

端到端验收测试 (E2E Acceptance Testing)

Acceptance testing is a phase in a typical software development process. It covers tests to see if the product has met the overall requirement specifications, and if it is “accepted” as ready for delivery. It is typically the last phase of testing before releasing the product to production. This could include user-based acceptance tests, business-based acceptance tests, or even alpha/beta testing.

验收测试是典型软件开发过程中的一个阶段。它涵盖了测试，以查看产品是否符合总体要求规格，以及是否已“准备就绪”交付产品。通常，这是将产品投入生产之前的最后测试阶段。这可能包括基于用户的验收测试，基于业务的验收测试，甚至是alpha / beta测试。

End-to-End (E2E) testing is one implementation of acceptance testing. It is an approach to acceptance testing, but the terms are not synonymous. It allows testing the flow of an application from start to finish to see if it is performing as designed. In the case of a web application, it would involve determining a user scenario and testing each of the steps the user would take in order. The test fails if the scenario is not completed successfully.

端到端 (E2E)测试是验收测试的一种实现。这是验收测试的一种方法，但是这些术语不是同义词。它允许从头到尾测试应用程序的流程，以查看它是否按设计执行。对于Web应用程序，它将涉及确定用户方案并测试用户将按顺序执行的每个步骤。如果方案未成功完成，则测试将失败。

Various tools exist to automate this process, simulating user interaction with the application.

存在各种工具来自动执行此过程，以模拟用户与应用程序的交互。

为什么选择Docker？ (Why Docker?)

Creating and running E2E tests is often considered a flaky and complex process. It requires a lot of set up that can still easily fail when run on different machines or in a CI (continuous integration) environment. Installing and maintaining different browsers and WebDrivers both for local tests and CI tests takes time. And even when done, it can still fail because of simple issues such as if the screen resolution on developer’s local machines, or in CI, is different.

创建和运行E2E测试通常被认为是一个脆弱而复杂的过程。它需要大量的设置，当它们在不同的计算机上或在CI(连续集成)环境中运行时，仍然很容易失败。为本地测试和CI测试安装和维护不同的浏览器和WebDriver都需要时间。即使完成，它仍然可能由于简单的问题而失败，例如开发人员的本地计算机或CI中的屏幕分辨率是否不同。

The standard advantages of Docker also apply: not having to deal with OS compatibility or having dependancies installed. To run the Selenium Server you would need Java installed (or at least be started/stopped explicitly). To run Express you would need Node.js, and for Chrome you’d need Chrome itself as well as ChromeDriver.

Docker的标准优势也适用：无需处理操作系统兼容性或安装依赖项。要运行Selenium Server，您需要安装Java( 或至少明确启动/停止 )。要运行Express，您需要Node.js；对于Chrome，您需要Chrome本身以及ChromeDriver。

When using Docker these dependancies are eliminated. You simply use different containers that already contain these, which will function precisely the same no matter on which machine they are run. When you then think how easy it is to build Docker into your CI, Dockerizing your test process becomes an obvious choice.

使用Docker时，消除了这些依赖性。您只需使用已经包含这些容器的不同容器，无论它们在哪台计算机上运行，它们的功能都将完全相同。然后，当您想到将Docker集成到CI中是多么容易时，对测试过程进行Docker化就成为显而易见的选择。

松散耦合的测试工具 (Loosely coupled testing tools)

There are several frameworks available when writing E2E tests, and for a newcomer it can be hard to know which to choose and invest time into. If you choose the wrong one, you’ll have wasted a lot of time.

编写端到端测试时，有几种可用的框架，对于新手来说，可能很难知道该选择哪一项并花费时间。如果您选择了错误的产品，那将会浪费很多时间。

This is where CodeceptJS comes into the picture. CodeceptJS is a testing framework that takes a scenario-driven, behaviour driven development (BDD) approach, with an API language that is easy for non-engineers to understand and use. However, perhaps even more importantly, it is backend agnostic. It is written on top of several popular testing libraries (WebDriverIO or Puppeteer, for example) and its single high level API communicates to whichever one you choose. It’s creators believe that

这就是CodeceptJS出现的地方。 CodeceptJS是一种测试框架，它采用场景驱动，行为驱动开发 (BDD)的方法，并且API语言易于非工程师理解和使用。但是，也许甚至更重要的是，它与后端无关。它是基于几种流行的测试库(例如WebDriverIO或Puppeteer)编写的，并且其单一的高级API可以与您选择的任何一个进行通信。创作者相信

Your tests should not be bound to your execution engine. Whether you choose Selenium or Puppeteer your tests should look almost the same. If you (later) feel the limitation of one engine you can easily switch your tests to other.

您的测试不应与执行引擎绑定。无论您选择Selenium还是Puppeteer，您的测试都应该看起来几乎相同。如果您(后来)感到一种引擎的局限性，则可以轻松地将测试切换到另一种。

测试工具层 (Layers of testing tools)

Let’s take a bottom-up approach to looking at how each layer builds on the last.

让我们采用一种自下而上的方法来研究每个层如何在最后一层构建。

It is worth initially referencing Selenium, a long running project with an actively used set of tools, which today is made up of Selenium WebDriver, Grid, Server, and IDE. In creating these tools they have set many industry standards, often confusingly named after the Selenium product they came from. This can be seen in ‘Selenium WebDriver’, and the ‘WebDriver wire protocol’ that was established in its development. Those applicable will be shown in more detail below.

最初值得一提的是Selenium ，这是一个长期运行的项目，具有一组活跃使用的工具，今天它由Selenium WebDriver，Grid，Server和IDE组成。在创建这些工具时，他们设置了许多行业标准，通常以其来源的Selenium产品来混淆地命名。这可以在“ Selenium WebDriver”和在其开发中建立的“ WebDriver有线协议”中看到。适用的内容将在下面更详细地显示。

浏览器 (Browser)

Any web browser: Chrome, Firefox, Internet Explorer, Safari, Opera, and so on. Often referred to as the ‘user agent’ in documentation.

任何网络浏览器：Chrome，Firefox，Internet Explorer，Safari，Opera等。在文档中通常称为“用户代理”。

W3C的WebDriver有线协议 (W3C’s WebDriver wire protocol)

The WebDriver wire protocol is a platform and language-neutral way of interacting with web browsers. It defines a common RESTful web service using JSON over HTTP in request/response pairs. It allows DOM elements to be manipulated from an external source, while also allowing navigation to web pages, user input, JavaScript execution, and more.

WebDriver有线协议是与Web浏览器进行交互的一种平台和语言无关的方式。它在请求/响应对中使用基于HTTP的JSON定义了通用的RESTful Web服务。它允许从外部来源操纵DOM元素，同时还允许导航到网页，用户输入，JavaScript执行等。

Initially written by Selenium for the Selenium WebDriver, this protocol has now reached the Editor’s Draft stage in becoming an official W3C standard.

该协议最初由Selenium为Selenium WebDriver编写，现已成为正式的W3C标准，进入了编辑草案阶段。

Other protocols do exit, but will not be covered in great detail here. All explanations will assume a backend that implements the WebDriver wire protocol.

确实会退出其他协议，但此处不会对其进行详细介绍。所有说明都将假定一个实现WebDriver有线协议的后端。

Another notable protocol is the Chrome DevTools protocol used by Puppeteer. Puppeteer does not use Selenium Server, and comes bundled with a recent version of Chromium intended for local use. If you wish to run Puppeteer in Docker, you can either use the CodeceptJS image (that comes with Puppeteer and Nightmare) or follow the official guide to creating a custom image that can support it.

另一个值得注意的协议是Puppeteer使用的Chrome DevTools协议。 Puppeteer不使用Selenium Server，而是捆绑了供本地使用的最新版本的Chromium 。如果希望在Docker中运行Puppeteer，则可以使用CodeceptJS映像 (Puppeteer和Nightmare随附)，也可以按照官方指南创建支持该映像的自定义映像。

浏览器WebDrivers (Browser WebDrivers)

These are browser specific implementations of the WebDriver wire protocol, for example ChromeDriver for Chrome or GeckoDriver for Firefox. Each acts as a standalone server to receive requests from the client where the WebDriver API is being used (generally where the tests are held). In order to communicate with the intended browser, the correct WebDriver implementation must be installed.

这些是金属丝的webdriver协议的浏览器的特定实现中，例如ChromeDriver用于Chrome或GeckoDriver用于Firefox。每个服务器都充当独立服务器，以接收来自使用WebDriver API的客户端 (通常在其中进行测试的客户端)的请求。为了与预期的浏览器进行通信，必须安装正确的WebDriver实现。

Selenium服务器 (Selenium Server)

If the tests are being run on the same machine that they are defined, then the client-side WebDriver API implementation used (described below) can communicate directly with the browser WebDriver and a Selenium Server is not required.

如果测试在定义的同一台计算机上运行，则所使用的客户端WebDriver API实现(如下所述)可以与浏览器WebDriver直接通信，并且不需要Selenium Server 。

However, if tests are to be run on a different machine, whether in CI, in a Selenium Grid setup across multiple machines or virtual machines (VMs), on a remote testing platform such as BrowserStack or SauceLabs, or within Docker, then a Selenium Server is used. It acts as a proxy to forward requests from the client-side WebDriver API to the correct browser WebDriver, and passes back the response from the browser.

但是，如果要在其他计算机上运行测试，无论是在CI中，跨多台计算机或虚拟机(VM)的Selenium Grid设置，在BrowserStack或SauceLabs等远程测试平台上还是在Docker中运行，那么Selenium使用服务器。它充当代理将请求从客户端WebDriver API转发到正确的浏览器WebDriver，并从浏览器传回响应。

客户端WebDriver实施 (Client-side WebDriver Implementation)

A variety of tools implement the client-side WebDriver wire protocol. Here the protocol can be seen as an API to send requests to the browser via the layers described above. Many tools using the protocol are full frameworks, such as WebDriverIO, that include their own test runners.

多种工具可实现客户端WebDriver有线协议。在这里，该协议可以看作是通过上述各层向浏览器发送请求的API。许多使用该协议的工具都是完整的框架，例如WebDriverIO ，其中包括自己的测试运行器。

Other implementations include: the original Selenium WebDriver, Protractor, Appium, and more.

其他实现包括：原始的 Selenium WebDriver，Protractor，Appium等。

The libraries of each aim to achieve the same results, but with slightly different focuses and API implementations. This can be as basic as Protractor’s browser.get(url) versus WebDriverIO’s browser.url(url).

每个库的目的都是达到相同的结果，但是重点和API实现略有不同。这可以与量角器的 browser.get(url)和WebDriverIO的 browser.url(url) 。

一种API来统治所有人 (One API to rule them all)

As described at the beginning of this section, this is where CodeceptJS comes into play. It refers to other client-side WebDriver protocol (or other) implementations as “helpers”, and allows you to specify the helper you prefer while using one API language. CodeceptJS does not care which protocol is being used by the helper chosen.

如本节开头所述，这是CodeceptJS发挥作用的地方。它将其他客户端WebDriver协议(或其他)实现称为“ 帮助程序 ”，并允许您在使用一种API语言时指定所需的帮助程序。 CodeceptJS不在乎所选助手正在使用哪种协议。

WebDriverIO, Puppeteer, Protractor, Nightmare and Appium are all current helpers that are available.

WebDriverIO，Puppeteer，量角器，梦Night和Appium都是当前可用的助手。

In CodeceptJS the previous command would be I.amOnPage(url) no matter which helper was chosen. This means that if you wanted to switch out your backend to one of the other helpers supported, your tests would not have to be re-written. It is possible to overwrite or add to the default API methods via custom classes should you wish.

在CodeceptJS中，无论选择了哪个助手，上一个命令都是I.amOnPage(url) 。这意味着，如果您想将后端切换到其他受支持的助手之一，则不必重写测试。如果需要，可以通过自定义类覆盖或添加到默认API方法。

创建一个测试项目 (Creating a test project)

With so many layers this starts to sound complex, but between CodeceptJS’s initialisation script and Docker images, we can quickly have a working example.

如此多的层听起来似乎很复杂，但是在CodeceptJS的初始化脚本和Docker映像之间，我们可以很快得到一个可行的示例。

我们将产生什么 (What we will produce)

We will write a simple test in CodeceptJS, specifying a WebDriverIO backend helper, that will communicate with a remote browser within the standalone-firefox Docker container. We will use the Express “hello world” app, but this could be replaced by any app you wish.

我们将在CodeceptJS中编写一个简单的测试，指定一个WebDriverIO后端助手，该助手将与独立firefox Docker容器内的远程浏览器进行通信。我们将使用Express“ hello world”应用程序，但可以用任何您想要的应用程序代替。

Once we have everything set up, we will be able to run only two commands to run the tests:

完成所有设置后，我们将只能运行两个命令来运行测试：

docker-compose up --build
docker-compose up --build
docker exec -it app npm run test:e2e
docker exec -it app npm run test:e2e

By running in two side by side terminal windows, we can see the containers running and the test executing in real time.

通过在两个并排的终端窗口中运行，我们可以实时查看容器的运行情况和测试的执行情况。

先决条件 (Prerequisites)

Docker, for whichever machine you are developing on.
Docker ，适用于您正在开发的任何机器。
You could also install Node.js, & npm for local development and debugging, but these can also be fully run within Docker.
您也可以安装Node.js和npm进行本地开发和调试，但是它们也可以在Docker中完全运行。

档案结构 (File structure)

We will be producing the file structure below. You can see a working example on Github.

我们将在下面生成文件结构。您可以在Github上看到一个有效的示例。

|-- .gitignore 
|-- output/
|-- Dockerfile
|-- app.js
|-- docker-compose.yml
|-- package.json
|-- package-lock.json
|-- e2eTests/
    |-- common_test.js
    |-- docker.conf.js

依存关系 (Dependencies)

First we will create our package.json with Express as a dependency and CodeceptJS and WebDriverIO as dev dependencies.

首先，我们将使用Express作为依赖关系以及CodeceptJS和WebDriverIO作为开发依赖关系来创建package.json 。

{
  "name": "example-standalone-firefox",
  "version": "1.0.0",
  "description": "Example of Dockerizing E2E testing",
  "scripts": {
    "start": "node app.js",
    "test:e2e": "codeceptjs run --steps --verbose --config=./e2eTests/docker.conf.js"
  },
  "dependencies": {
    "express": "^4.16.3"
  },
  "devDependencies": {
    "codeceptjs": "^1.2.0",
    "webdriverio": "^4.12.0"
  }
}

We have also included two scripts, one to run the Express app we will add (npm run start), and one to run our CodeceptJS test (npm run test:e2e).

我们还包括了两个脚本，一个用于运行我们将添加的Express应用程序( npm run start )，另一个用于运行CodeceptJS测试( npm run test:e2e )。

codeceptjs run --steps --verbose --config=./e2eTests/docker.conf.js

--steps is great for showing output in the terminal as tests are running, while --verbose extends the level of detail even further. --verbose is likely not needed as standard, but is good for seeing how the example works. --config shows us the path to the backend configuration file, in this case kept in a separate e2eTests directory.

--steps非常适合在测试运行时在终端中显示输出，而--verbose可以进一步扩展详细程度。 --verbose可能不需要作为标准，但是对于查看示例的工作方式很有用。 --config向我们显示了后端配置文件的路径，在这种情况下，该文件保存在单独的e2eTests目录中。

我们的应用 (Our app)

Next we need an app to test. For this we will run the Express “hello world” app from app.js.

接下来，我们需要一个应用程序进行测试。为此，我们将运行来自app.js的Express“ hello world ”应用程序。

const express = require('express');

const app = express();

app.get('/', (req, res) => res.send('Hello World!'));

const server = app.listen(3000, () => {
    const port = server.address().port
    console.log(`Example app listening on port ${port}`)
 })

You can view this using npm run start and then going to localhost:3000 in your browser.

您可以使用npm run start查看此内容，然后在浏览器中转到localhost:3000 。

测试配置 (Test configuration)

CodeceptJS requires two files, a configuration file and a test file. The test file is extremely simple: it tests that the app can be accessed, saves a screenshot, and checks that the text “Hello” can be seen on the page.

CodeceptJS需要两个文件，一个配置文件和一个测试文件。测试文件非常简单：它测试可以访问该应用程序，保存屏幕截图并检查在页面上是否可以看到文本“ Hello”。

Feature('Basic test');

Scenario('navigate to homepage', I => {
  I.amOnPage('http://app:3000');
  I.saveScreenshot('frontpageScreenshot.png');
  I.see('Hello');
});

The first indication that we will be using multiple Docker containers is shown here in the use of app:3000 rather than localhost:3000. localhost can only be understood from within a single container. If a command is being run from another container (in this case by Firefox in our second Selenium container), then it needs a more definitive reference. We could use the first container’s IP address directly, but using the container’s name is much easier to read.

使用app:3000而不是localhost:3000的第一个迹象表明我们将使用多个Docker容器。 localhost只能从单个容器中理解。如果命令是从另一个容器运行的(在本例中是Firefox在我们的第二个Selenium容器中运行的)，则它需要更明确的参考。我们可以直接使用第一个容器的IP地址，但是使用容器的名称更容易阅读。

In this case, app will be the name of the container that is running the app, so we can use app:3000. Don’t worry if you don’t follow this yet, seeing how our docker-compose.yml is structured will help.

在这种情况下， app将是运行该应用程序的容器的名称，因此我们可以使用app:3000 。不用担心，如果您还没有遵循，请看看我们docker-compose.yml的结构如何会有所帮助。

We also need a main configuration file. This can be written in JSON or JS, but here we use JS. Let’s look at this:

我们还需要一个主配置文件。可以用JSON或JS编写，但是这里我们使用JS。让我们看一下：

exports.config = {
  tests: './*_test.js',    // how to know which files are test files
  output: './output',      // where to save screenshots
  helpers: {
   WebDriverIO: {               // which backend helper to use
     url: 'http://app:3000',    // a base URL to start on
     host: 'firefox-container', // identifying where selenium runs
     browser: 'firefox',        // a series of config options
     smartWait: 5000,              
     waitForTimeout: 10000,
     desiredCapabilities: {        // for a demo app we do not want 
         acceptInsecureCerts: true,   to worry about SSL certs
     }
   },
  },
  name: 'codeceptjs-docker',
};

设置Docker (Setting up Docker)

Referring back to the diagram above in the “What we will produce” section, we can see that we will be using two Docker containers. They must be aware of each other and be able to communicate. One will contain our app and tests, and one a Selenium Server, GeckoDriver, and Firefox, so that we do not need Firefox installed on our local machine.

回顾上面“我们将产生的东西”部分中的图，我们可以看到我们将使用两个Docker容器。他们必须彼此了解并能够交流。一个将包含我们的应用程序和测试，一个将包含Selenium服务器，GeckoDriver和Firefox，因此我们不需要在本地计算机上安装Firefox。

Docker Compose is a tool for “defining and running multi-container Docker applications.” It starts Docker containers with the command docker-compose up, and stops them with docker-compose down. If a user defined Dockerfile is being used, --build is used to build it, either the first time docker-compose up is run, or if changes have been made to the Dockerfile. docker-compose.yml is the file that defines what the up command will do.

Docker Compose是用于“定义和运行多容器Docker应用程序”的工具。它使用docker-compose up 命令启动Docker容器，并使用docker-compose down停止它们。如果正在使用用户定义的Dockerfile，则使用--build来构建它，或者是第一次运行docker docker-compose up ，或者是对Dockerfile进行了更改。 docker-compose.yml是定义up命令将执行的操作的文件。

Our next step is to create this docker-compose.yml. It is heavily dependant on indentation.

下一步是创建此docker-compose.yml 。它在很大程度上取决于缩进。

version: "2"        // which version of compose syntax you are using
services:
  app:
    container_name: app  // explicit so we can use this for app:3000
    build: .             // a self defined Dockerfile, see below
    ports:               // exposes port 3000 (where express runs)
      - "3000:3000"         to other containers, and to our local       
    depends_on:             browser
      - firefox-container
    volumes:             // maps so changes to these can be seen
      - ./e2eTests:/e2eTests
      - ./package.json:/package.json
      - ./package-lock.json:/package-lock.json
      - ./.gitignore:/.gitignore
      - ./app.js:/app.js

  firefox-container:      // we'll look at this below
    container_name: firefox-container
    image: selenium/standalone-firefox:3.12.0-americium
    volumes:
      - /dev/shm:/dev/shm
    ports:
      - "4444:4444"

For our Selenium Server, drivers, and browser, we use a pre-defined image available from the public Docker Hub called selenium/standalone-firefox. We specify which version we want, 3.12.0-americium. If we did not specify this the latest image would be used by default (which is not a bad thing). As advised, we configure it to share the host’s memory to prevent the browser being run from crashing, and expose port 4444, the default Selenium port. We also map this to port 4444 on our local machine, allowing us to visit localhost:4444/wd/hub/static/resource/hub.html in our browser.

对于Selenium Server，驱动程序和浏览器，我们使用可从公共Docker Hub获得的预定义映像，称为selenium / standalone-firefox 。我们指定所需的版本3.12.0-americium。如果我们未指定此选项，则默认情况下将使用最新图像(这不是一件坏事)。根据建议，我们将其配置为共享主机的内存以防止浏览器崩溃，并公开端口4444(默认的Selenium端口)。我们还将其映射到本地计算机上的端口4444，从而允许我们在浏览器中访问localhost:4444/wd/hub/static/resource/hub.html 。

For our app container, we are not just using an image built by someone else, but are writing a Dockerfile to specify how our app is built. In the same way as the selenium-firefox container we expose a port, 3000 in this case, as that is where Express runs by default. By mapping this using 3000:3000 we are able to visit localhost:3000 while the app is being run in Docker to see it in our local browser.

对于我们的app容器，我们不仅在使用别人构建的映像，还在编写Dockerfile来指定我们的应用程序的构建方式。以与selenium-firefox容器相同的方式，我们公开了一个端口(在本例中为3000)，因为Express是默认运行的端口。通过使用3000:3000映射此映射，我们可以在Docker中运行应用程序时访问localhost:3000 ，以在本地浏览器中查看它。

Our Dockerfile uses the public node:carbon image as a base, sets the working directory, copies some files from our local machine to the container, runs npm install so that the container has all needed dependencies, and then runs the npm start command we specified.

我们的Dockerfile使用public node:carbon映像作为基础，设置工作目录，将本地计算机中的一些文件复制到容器中，运行npm install以使容器具有所有必需的依赖项，然后运行我们指定的npm start命令。

FROM node:carbon 
WORKDIR ./ 
COPY ./package.json ./package-lock.json ./app.js ./ 
RUN npm install 
CMD [ "npm", "start" ]

This means that when docker-compose up --build is run, it will follow these steps, resulting in our app being ready and running on port 3000.

这意味着当docker-compose up --build运行时，它将遵循以下步骤，从而导致我们的应用已准备就绪并在端口3000上运行。

Note: The --build flag is only needed the first time docker-compose up is run, or if changes have been made to our Dockerfile or the steps executed within it. For example, if we added another dependency in our package.json then Docker would not know about it if we did not rebuild our image, as npm install is run within the Dockerfile.

注意：仅在第一次运行docker docker-compose up或对Dockerfile或其中执行的步骤进行了更改时才需要--build标志。例如，如果我们在package.json添加了另一个依赖关系，那么如果我们不重建映像，Docker将不会知道它，因为npm install在Dockerfile中运行。

运行测试 (Running tests)

We now have a simple app, tests written for it, and a Docker Compose configuration that will run both our app, a Selenium Server, and Firefox.

现在，我们有一个简单的应用程序，为此编写的测试以及一个可以运行我们的应用程序，Selenium Server和Firefox的Docker Compose配置。

We can start all of these using docker-compose up --build.

我们可以使用docker-compose up --build开始所有这些操作。

To run commands within a running Docker container, docker exec can be used from another terminal window. The format is:

要在正在运行的Docker容器中运行命令，可以在另一个终端窗口中使用docker exec 。格式为：

docker exex <flags> <container_name&gt; <command>

docker exex <flags> <container_name&g t; <命令>

The command we will use is:

我们将使用的命令是：

docker exec -it app npm run test:e2e

We can now see our test running, and see each step as it is performed! From here we can extend what our test does, add additional tests (ending the filenames in _test.js), and use the same two commands to run them. No more setup is needed.

现在，我们可以看到我们的测试正在运行，并看到执行的每个步骤！从这里我们可以扩展测试的功能，添加其他测试(以_test.js结尾的文件名)，并使用相同的两个命令来运行它们。无需其他设置。

You now have an easily extensible E2E testing setup that can be relied on to run the same way no matter which machine it is run on. It was written with API commands that can be easily understood by both developers and non-developers. All that remains now is to decide which behaviour your app should be capable of, and test it!

现在，您可以轻松扩展E2E测试设置，无论运行在哪台计算机上，都可以依靠它以相同的方式运行。它是用API命令编写的，开发人员和非开发人员都可以轻松理解。现在剩下的就是确定您的应用应具备的行为并进行测试！

最后的话 (Final words)

SeleniumHQ also produces Docker images for Chrome testing, and images for using Selenium Grid for running multiple instances of Chrome and Firefox at one time.

SeleniumHQ还生成用于Chrome测试的 Docker 映像，以及用于使用Selenium Grid一次运行多个Chrome和Firefox实例的映像。

CodeceptJS also has instructions for running CodeceptJS in Docker, so that it does not need to be specified as a dependency in your app.

CodeceptJS还具有在Docker中运行CodeceptJS的说明，因此无需在您的应用程序中将其指定为依赖项。

A more technical, but still starter level description of how Docker works can be seen in the first section of the post I wrote titled A beginner’s guide to Amazon’s Elastic Container Service.

在我撰写的标题为Amazon Elastic Container Service的新手指南的文章的第一部分中，可以找到有关Docker工作原理的更技术性但入门级的描述。

Thanks for reading ?

谢谢阅读？

Update: I recently wrote Customising CodeceptJS e2e tests for anyone looking for next steps in testing complex applications.

更新：我最近为希望在复杂应用程序中进行下一步测试的任何人编写了Customizing CodeceptJS e2e测试。

资源资源 (Resources)

Github of CodeceptJS Docker examples
Github的CodeceptJS Docker示例
CodeceptJS QuickStart guide
CodeceptJS快速入门指南
Selenium WebDriver Architecture
Selenium WebDriver架构
Selenium WebDriver Flow
Selenium WebDriver流程

翻译自: https://www.freecodecamp.org/news/how-to-dockerize-your-end-to-end-acceptance-tests-dbb593acb8e0/

端到端测试

cumifi2519

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
端到端测试_如何将您的端到端验收测试打包

端到端测试This article serves as a “how-to” guide for using Selenium Docker images alongside CodeceptJS and an Express server. 本文是将Selenium Docker映像与CodeceptJS和Express服务器一起使用的“操作指南”。 In it, we will cover:...
复制链接

扫一扫