Skip to main content
Cypress应用

第一个测试

info
你将学到​
  • 如何使用示例应用在Cypress中编写第一个端到端测试
  • 如何使用Cypress命令与页面元素交互
  • 如何对应用程序状态进行断言

添加测试文件​

假设你已经成功 安装Cypress并 打开Cypress，现在是时候添加 你的第一个测试了。我们将使用创建新的空测试规范按钮来完成这个操作。

Cypress界面，突出显示创建新的空测试规范按钮

点击后，你会看到一个对话框，可以输入新测试规范的名称。暂时接受默认名称即可。

新测试规范路径对话框

新生成的测试规范会显示在确认对话框中。只需点击✕按钮关闭它。

新测试规范添加确认对话框

创建文件后，你应该会立即在端到端测试规范列表中看到它。Cypress会监控你的测试文件是否有任何更改，并自动显示这些更改。

Cypress显示包含新创建测试规范的列表

尽管我们还没有编写任何代码——这没关系——让我们点击你的新测试规范，观察Cypress如何启动它。Cypress会访问https://example.cypress.io，测试将通过。

Cypress显示新创建的测试规范通过

编写第一个测试​

现在是时候编写你的第一个测试了。我们将：

  1. 编写第一个通过的测试。
  2. 更新它使其失败。
  3. 观察Cypress实时重新加载。

打开你喜欢的IDE，将测试规范的内容替换为以下代码。

describe('我的第一个测试', () => {
  it('没有做太多事情！', () => {
    expect(true).to.equal(true)
  })
})

保存更改后，你应该会看到浏览器重新加载。

虽然这个测试没有实际作用，但这是我们的第一个通过的测试！✅

在命令日志中，你会看到Cypress显示测试套件、测试和你的第一个断言（应该是绿色的通过状态）。

我的第一个测试在Cypress中显示为通过
info

注意Cypress在右侧显示了一条关于这是默认页面的消息。Cypress假设你会想要访问互联网上的某个URL——但它也可以在没有这个操作的情况下正常工作。

现在让我们编写第一个失败的测试。

describe('我的第一个测试', () => {
  it('没有做太多事情！', () => {
    expect(true).to.equal(false)
  })
})

再次保存后，你会看到Cypress以红色显示失败的测试，因为true不等于false。

Cypress还会显示堆栈跟踪和断言失败的代码帧（如果可用）。你可以点击蓝色的文件链接，在你首选的文件打开器中打开发生错误的文件。要了解更多关于错误显示的信息，请阅读调试错误。

失败的测试

Cypress为你提供了测试套件、测试和断言的可视化结构。很快你还会看到命令、页面事件、网络请求等。

info

什么是_describe_、it_和_expect？

所有这些函数都来自Cypress内置的捆绑库。

Cypress基于这些你可能已经熟悉的流行工具和框架构建。如果不熟悉，也没关系。

tip
使用ESlint？

查看我们的Cypress ESLint插件。

编写一个_真正的_测试​

一个可靠的测试通常包含3个阶段：

  1. 设置应用程序状态。
  2. 执行一个操作。
  3. 对结果应用程序状态进行断言。

你可能也见过这种表述为"Given, When, Then"或"Arrange, Act, Assert"。但核心思想是：首先将应用程序置于特定状态，然后在应用程序中执行导致其变化的操作，最后检查结果应用程序状态。

今天，我们将从狭义的角度来看这些步骤，并将它们清晰地映射到Cypress命令：

  1. 访问一个网页。
  2. 查询一个元素。
  3. 与该元素交互。
  4. 对页面内容进行断言。

第一步：访问页面​

首先，让我们访问一个网页。在这个例子中，我们将访问我们的Kitchen Sink应用程序，这样你就可以在不担心找到测试页面的情况下尝试Cypress。

我们可以将要访问的URL传递给cy.visit()。让我们用实际访问页面的测试替换之前的测试：

describe('我的第一个测试', () => {
  it('访问Kitchen Sink', () => {
    cy.visit('https://example.cypress.io')
  })
})

保存文件并切换回Cypress测试运行器。你可能会注意到几件事：

  1. 命令日志现在显示新的VISIT操作。
  2. Kitchen Sink应用程序已加载到应用程序中。
  3. 测试是绿色的，尽管我们没有做任何断言。
  4. VISIT显示蓝色挂起状态，直到页面完成加载。

如果这个请求返回非2xx状态码，如404或500，或者应用程序代码中有JavaScript错误，测试将会失败。

第二步：查询元素​

现在我们已经加载了一个页面，需要对其执行一些操作。为什么不点击页面上的一个链接呢？听起来很简单，让我们找一个我们喜欢的...比如type？

要通过内容找到这个元素，我们将使用cy.contains()。

让我们将其添加到测试中，看看会发生什么：

describe('我的第一个测试', () => {
  it('找到内容"type"', () => {
    cy.visit('https://example.cypress.io')

    cy.contains('type')
  })
})

我们的测试现在应该在命令日志中显示CONTAINS，并且仍然是绿色的。

即使没有添加断言，我们也知道一切正常！这是因为许多Cypress命令都内置了如果找不到预期内容就会失败的功能。这被称为隐式断言。

为了验证这一点，将type替换为页面上没有的内容，如hype。你会注意到测试变红，但大约4秒后才失败！

你能看到Cypress在幕后做了什么吗？它自动等待并重试，因为它期望内容最终会在DOM中找到。它不会立即失败！

测试因找不到内容'hype'而失败
caution
错误消息

我们在Cypress中精心编写了数百条自定义错误消息，试图清楚地解释出了什么问题。在这个例子中，Cypress超时重试在整个页面中查找内容hype。要了解更多关于错误显示的信息，请阅读调试错误。

在添加另一个命令之前，让我们让这个测试重新通过。将hype替换回type。

第三步：点击元素​

好的，现在我们想点击我们找到的链接。我们该怎么做？在之前的命令末尾添加一个.click()命令，像这样：

describe('我的第一个测试', () => {
  it('点击链接"type"', () => {
    cy.visit('https://example.cypress.io')

    cy.contains('type').click()
  })
})

你几乎可以像读一个小故事一样阅读它！Cypress称之为"链式调用"，我们通过链式调用来构建测试，以声明式的方式真正表达应用程序的行为。

还要注意，应用程序在点击后进一步更新，跟随链接并显示目标页面：

现在我们可以对这个新页面进行断言了！

info

✨ 通过在 Cypress 测试文件中添加特殊的三斜杠注释行，即可获得 IntelliSense 智能提示功能。了解更多关于智能代码补全的信息。

第四步：进行断言​

让我们对我们点击进入的新页面上的某些内容进行断言。也许我们想确保新的URL是预期的URL。我们可以通过查找URL并使用.should()链接一个断言来实现。

以下是它的样子：

describe('我的第一个测试', () => {
  it('点击"type"导航到新URL', () => {
    cy.visit('https://example.cypress.io')

    cy.contains('type').click()

    // 应该在一个包含'/commands/actions'的新URL上
    cy.url().should('include', '/commands/actions')
  })
})

添加更多命令和断言​

在给定的测试中，我们不仅限于单一的交互和断言。事实上，应用程序中的许多交互可能需要多个步骤，并且可能会以多种方式改变你的应用程序状态。

我们可以通过在这个测试中添加另一个链式调用来继续交互和断言，以交互和验证这个新页面上元素的行为。

我们可以使用cy.get()根据类选择元素。然后我们可以使用.type()命令在选定的输入框中输入文本。最后，我们可以使用另一个.should()验证输入框的值反映了输入的文本。

一般来说，你的测试结构应该遵循查询 -> 查询 -> 命令或断言。最佳实践是在操作命令之后不要链接任何内容；有关为什么这样的更多细节，请参阅我们的重试能力指南。

describe('我的第一个测试', () => {
  it('获取、输入和断言', () => {
    cy.visit('https://example.cypress.io')

    cy.contains('type').click()

    // 应该在一个包含'/commands/actions'的新URL上
    cy.url().should('include', '/commands/actions')

    // 获取一个输入框，输入内容
    cy.get('.action-email').type('fake@email.com')

    // 验证值已更新
    cy.get('.action-email').should('have.value', 'fake@email.com')
  })
})
caution

我们通常不建议通过类名选择和查找元素，但在这里这样做是因为我们查询的是一个外部站点，有时这是我们唯一可以使用的。

有关我们关于选择器最佳实践的更多信息，请参阅这里的指南。

就是这样：一个简短的Cypress测试，访问一个页面，找到并点击一个链接，验证URL，然后验证新页面上一个元素的行为。如果我们大声读出来，可能会像这样：

note
  1. 访问：https://example.cypress.io
  2. 找到内容为type的元素
  3. 点击它
  4. 获取URL
  5. 断言它包含：/commands/actions
  6. 获取类为action-email的输入框
  7. 在输入框中输入fake@email.com
  8. 断言输入框反映了新值

或者用_Given_、When、_Then_语法：

note
  1. Given 用户访问https://example.cypress.io
  2. When 他们点击标签为type的链接
  3. 并且他们在类为action-email的输入框中输入"fake@email.com"
  4. Then URL应该包含/commands/actions
  5. 并且[class="action-email"]输入框的值为"fake@email.com"

嘿，这是一个非常清晰的测试！我们不需要说明_如何_工作，只是我们想要验证一系列特定的事件和结果。

info
页面过渡

值得注意的是，这个测试跨越了两个不同的页面。

  1. 初始的cy.visit()
  2. .click()到新页面

Cypress会自动检测诸如页面过渡事件之类的事情，并会自动暂停运行命令，直到下一个页面完成加载。

如果下一页没有完成加载阶段，Cypress会结束测试并显示错误。

在底层——这意味着你不必担心命令意外针对过时的页面运行，也不必担心命令针对部分加载的页面运行。

我们之前提到Cypress在查找DOM元素之前会等待4秒超时——但在这种情况下，当Cypress检测到页面过渡事件时，它会自动将单个PAGE LOAD事件的超时增加到60秒。

换句话说，基于命令和发生的事件，Cypress会自动调整其预期的超时时间以匹配Web应用程序的行为。

这些各种超时定义在配置文档中。

使用Cypress Studio记录测试​

如果你想以最小的代码方式创建测试，可以使用Cypress Studio记录浏览器交互并生成测试。访问我们的指南了解更多信息。

测试你不控制的应用程序​

danger

**反模式：**尝试访问或与你无法控制的站点或服务器交互。

在本指南中，我们测试的是我们的示例应用程序： https://example.cypress.io。 然而，你应该仔细考虑测试你不控制或所有者未邀请你测试的应用程序。 为什么？

  • 它们可能启用了安全功能，阻止Cypress工作，例如检测Cypress脚本使用。这可能会阻止你的访问，并使应用程序网站看起来无响应。
  • 它们有可能随时更改，这会破坏测试。
  • 它们可能进行A/B测试，这使得无法获得一致的结果。

一般来说，Cypress的目的是成为你每天用来构建和测试自己应用程序的工具，而不是通用的Web自动化工具。然而，这是一个指导原则而不是硬性规定，对于某些类型的应用程序有许多很好的例外理由：

  • 它们专门设计用于与第三方集成，例如SSO提供商。
  • 它们为你提供补充服务，例如SaaS控制面板或分析。
  • 它们重用你的内容或为你控制的应用程序提供插件。

这里的关键是仔细权衡相关测试的好处与这些测试可能引入的干扰和不稳定性。

另请参阅访问外部站点，在我们的最佳实践页面上，讨论了必要时采用的策略。

下一步​

使用搜索框查找相关文档

目录