End-to-end testing with GitLab CI/CD and WebdriverIO
原文:https://docs.gitlab.com/ee/ci/examples/end_to_end_testing_webdriverio/
End-to-end testing with GitLab CI/CD and WebdriverIO
Review App很棒:对于每个合并请求(或分支),都可以将新代码复制并部署到新的类似于生产的实时环境中,从而非常省力地评估更改的影响. 因此,当我们使用像Dependencies.io这样的依赖项管理器时,它可以提交具有更新的依赖项的合并请求,并且很明显,仍然可以正确地构建和部署应用程序. 毕竟,您可以看到它正在运行!
但是,查看新部署的代码以检查其外观和行为是否仍符合预期是重复的手动工作,这意味着它是自动化的主要候选对象. 这就是自动端到端测试的目的 :让计算机在几种简单的场景下运行,这些场景要求您的应用程序的所有层(从前端到数据库)都具有适当的功能.
在本文中,我们将讨论如何编写这样的端到端测试,以及如何设置 GitLab CI / CD 以逐分支的基础针对新代码自动运行这些测试. 在本文的范围内,我们将引导您完成设置 GitLab CI / CD 的过程,以使用 WebdriverIO 端对端测试基于 JavaScript 的应用程序,但是一般策略应延续到其他语言. 我们假设您熟悉 GitLab, GitLab CI / CD , Review Apps ,并在本地运行您的应用程序,例如,在localhost:8000
.
What to test
在广泛使用的测试金字塔策略中 ,端到端测试的行为更像是一种保护措施: 大多数代码应包含在单元测试中 ,以使您可以轻松地确定问题的根源. 相反,您可能希望将端到端测试的数量限制为刚好足以使您确信部署按预期进行,基础结构已启动并正在运行以及代码单元可以很好地协同工作.
Selenium and WebdriverIO
Selenium是一款可以控制 Web 浏览器的软件,例如,使它们能够访问特定的 URL 或与页面上的元素进行交互. 它可以通过多种编程语言进行编程控制. 在本文中,我们将使用WebdriverIO JavaScript 绑定,但是一般概念应该可以很好地延续到Selenium 支持的其他编程语言中 .
Writing tests
您可以使用WebdriverIO 支持的多个测试框架编写测试. 我们将在这里使用茉莉花 :
describe('A visitor without account', function(){
it('should be able to navigate to the homepage from the 404 page', function(){
browser.url('/page-that-does-not-exist');
expect(browser.getUrl()).toMatch('page-that-does-not-exist');
browser.element('.content a[href="/"]').click();
expect(browser.getUrl()).not.toMatch('page-that-does-not-exist');
});
});
WebdriverIO 提供了describe
, it
和browser
的功能. 让我们一一分解.
函数describe
允许您对相关测试进行分组. 例如,如果您想对多个测试运行相同的初始化命令(使用beforeEach
),例如确保您已登录,则这将很有用.
it
定义了单个测试的功能.
browser
对象是 WebdriverIO 的特长. 它提供了大多数WebdriverIO API 方法 ,这些方法是引导浏览器的关键. 在这种情况下,我们可以使用browser.url
来访问/page-that-does-not-exist
以访问 404 页面. 然后,我们可以使用browser.getUrl
验证当前页面确实在我们指定的位置. 要与页面进行交互,我们只需将 CSS 选择器传递给browser.element
即可访问页面上的元素并与其进行交互-例如,单击返回首页的链接.
上面显示的简单测试如果通过则可以给我们很大的信心:我们知道我们的部署成功了,这些元素在页面上可见,并且实际的浏览器可以与它交互,并且路由按预期工作. 所有这些仅用免费的空格就可以在 10 行中完成! 加上后续的单元测试和成功完成的管道,您可以完全确信,依赖项升级不会破坏任何内容,甚至无需查看您的网站.
Running locally
稍后我们将在 CI / CD 中运行上述测试. 但是,在编写测试时,如果您不必等待管道成功以检查它们是否按照您期望的方式工作,那么它会有所帮助. 换句话说,让它在本地运行.
确保您的应用程序在本地运行. 如果使用 Webpack,则可以使用Webpack Dev Server WebdriverIO 插件在执行测试之前自动启动开发服务器.
The WebdriverIO documentation has an overview of all configuration options, but the easiest way to get started is to start with WebdriverIO’s default configuration, which provides an overview of all available options. The two options that are going to be most relevant now are the specs
option, which is an array of paths to your tests, and the baseUrl
option, which points to where your app is running. And finally, we will need to tell WebdriverIO in which browsers we would like to run our tests. This can be configured through the capabilities
option, which is an array of browser names (e.g. firefox
or chrome
). It is recommended to install selenium-assistant to detect all installed browsers:
const seleniumAssistant = require('selenium-assistant');
const browsers = seleniumAssistant.getLocalBrowsers();
config.capabilities = browsers.map(browser => ({ browserName: browser.getId() }));
但是,当然,简单的配置config.capabilities = ['firefox']
也可以.
如果已将 WebdriverIO 安装为依赖项( npm install --save-dev webdriverio
),则可以在package.json
中的scripts
属性中添加一行,该行运行wdio
并将配置文件的路径作为值,例如:
"confidence-check": "wdio wdio.conf.js",
然后,您可以使用npm run confidence-check
执行测试,之后您实际上会看到一个新的浏览器窗口,与您指定的应用交互.
Configuring GitLab CI/CD
这使我们进入了令人兴奋的部分:我们如何在 GitLab CI / CD 中运行它? 为此,我们需要做两件事:
- 设置实际上具有浏览器的CI / CD 作业 .
- 更新我们的 WebdriverIO 配置以使用那些浏览器来访问评论应用程序.
对于本文的范围,我们定义了一个附加的CI / CD 阶段 confidence-check
,该confidence-check
在部署审阅应用程序的阶段之后执行. 它使用node:latest
Docker image . 但是,WebdriverIO 会启动实际的浏览器来与您的应用程序进行交互,因此我们需要安装并运行它们. 此外,WebdriverIO 使用 Selenium 作为控制不同浏览器的通用接口,因此我们也需要安装和运行 Selenium. 幸运的是,Selenium 项目提供了分别为 Firefox 和 Chrome 提供的 Docker 映像standalone-firefox和standalone-chrome . (由于 Safari 和 Internet Explorer / Edge 不是开源的,并且不适用于 Linux,因此很遗憾,我们无法在 GitLab CI / CD 中使用它们.)
GitLab CI / CD 使用service
属性将这些图像链接到我们的confidence-check
作业变得轻而易举,这使得 Selenium 服务器可以在基于图像名称的主机名下使用. 我们的工作配置如下所示:
e2e:firefox:
stage: confidence-check
services:
- selenium/standalone-firefox
script:
- npm run confidence-check --host=selenium__standalone-firefox
对于 Chrome 同样如此:
e2e:chrome:
stage: confidence-check
services:
- selenium/standalone-chrome
script:
- npm run confidence-check --host=selenium__standalone-chrome
现在我们有一项工作可以运行端到端测试,我们需要告诉 WebdriverIO 如何连接到与其并排运行的 Selenium 服务器. 通过将host
选项的值作为参数传递给npm run confidence-check
命令在命令行上npm run confidence-check
,我们已经作弊了. 但是,我们仍然需要告诉 WebdriverIO 使用哪个浏览器.
GitLab CI / CD 提供了许多有关当前 CI 作业的信息的变量 . 我们可以使用此信息根据正在运行的作业动态设置 WebdriverIO 配置. 更具体地说,我们可以根据当前正在运行的作业的名称,告诉 WebdriverIO 使用哪个浏览器执行测试. 我们可以在 WebdriverIO 的配置文件中执行此操作,在上面将其命名为wdio.conf.js
:
if(process.env.CI_JOB_NAME) {
dynamicConfig.capabilities = [
{ browserName: process.env.CI_JOB_NAME === 'e2e:chrome' ? 'chrome' : 'firefox' },
];
}
同样,我们可以告诉 WebdriverIO 审阅应用程序在哪里运行-在本示例中,它位于<branch name>.flockademic.com
:
if(process.env.CI_COMMIT_REF_SLUG) {
dynamicConfig.baseUrl = `https://${process.env.CI_COMMIT_REF_SLUG}.flockademic.com`;
}
并且我们可以确保仅当不使用if (!process.env.CI)
在 CI 中运行时,才使用本地特定的配置. 基本上,这是在 GitLab CI / CD 上进行端到端测试所需的全部成分!
回顾一下,我们的.gitlab-ci.yml
配置文件如下所示:
image: node:8.10
stages:
- deploy
- confidence-check
deploy_terraform:
stage: deploy
script:
# Your Review App deployment scripts - for a working example please check https://gitlab.com/Flockademic/Flockademic/blob/5a45f1c2412e93810fab50e2dab8949e2d0633c7/.gitlab-ci.yml#L315
e2e:firefox:
stage: confidence-check
services:
- selenium/standalone-firefox
script:
- npm run confidence-check --host=selenium__standalone-firefox
e2e:chrome:
stage: confidence-check
services:
- selenium/standalone-chrome
script:
- npm run confidence-check --host=selenium__standalone-chrome
What’s next
如果您要自己进行设置并希望了解生产项目的工作配置,请参阅:
WebdriverIO 还可以做更多的事情. 例如,您可以配置一个screenshotPath
以告诉 WebdriverIO 在测试失败时进行截图. 然后告诉 GitLab CI / CD 存储这些工件 ,您将能够看到 GitLab 中出了什么问题.