2

我个人认为playwright这是一种进入系统/端到端测试方向的工具。因此，我使用playwright+jest来构建用户旅程并将它们集成到 CI/CD 流程中。

由于playwright创建了自己的测试运行器，具有拍摄视频和跟踪故障等有用功能，因此jest从@playwright/test. 在他们的主页上playwright建议使用测试装置，所以我绝对想将它们包含在开关中。

下面我以亚马逊为例。

使用playwright+jest我做的第一件事是为环境的通用设置创建一个函数：

function setupSuite({ browserOptions, userConfig }){
  // create playwright browser and use browserOptions as overrides
  // create page from browser
  // register self-implemented trace and screenshot reporters to page
  // go to baseUrl of current environment (e.g. local, branch etc..)
  // click on cookie banner, since it's blocking the UI
  // create a user based on userConfig (e.g. user has amazon prime user? payment options? etc.)
  // return { browser, page, user, ... }
}

当然还有一个再次清理所有内容的功能：

function teardownSuite(suite){
  // close browser
  // delete user
  // etc..
}

然后我会为每个用户旅程使用一个文件。在亚马逊的情况下，用户旅程可能是订单的成功处理：

describe("Successful Order", () => {
  let suite

  beforeAll(async () => {
    const userConfig = { isPrime: false, paymentOptions: [ "paypal", "visa" ] }
    suite = await setupBrowser({ userConfig })
    
    // I actually extracted that logic in a function to be able to use it in other tests too,
    // but just want to make clear whats happening here
    const { page, user } = suite
    await page.fill(".login-username-input", user.username)
    await page.fill(".login-password-input", user.password)
    await page.click(".login-submit-button")
  })

  afterAll(() => teardownSuite(suite))

  test("search for toothbrush with suggestions", async () => {
     const { page } = suite
     await page.fill(".search-input", "tooth")
     await page.click("text='toothbrush")
     // hit enter
     // do some assertions to check if the search was really successful
  })
  
  test("click on first item and add to chart", async () => {
     // page actions and assertions
  })

  test("go back, click on second item and add to chart", async () => {
     // page actions and assertions
  })

  test("go to chart and pay", async () => {
     // page actions and assertions
  })

  test("check order confirmation mail", async () => {
     // page actions and assertions
  })
})

如您所见，我将测试分成逻辑部分以使其更具可读性，并查看它在哪个步骤（test块）失败。

将其迁移到@playwright/test+ 固定装置的最佳方法是什么？

  • 您将如何迁移setupSuite/ teardownSuite？是的，您可以使用夹具，但setupSuite需要像 userConfig 这样的参数。是否可以有参数化的夹具？
  • 您将如何使用固定装置构建测试？例如，如果您想模拟完整的用户旅程，那么测试将变得比仅测试登录更大。然后，一个测试块将有很多行，而无法构造它们。
  • 是否可以设置一个页面以便在所有测试中共享？beforeAll钩子不接收任何页面，并且每个块test总是接收自己的页面。test这意味着块之间没有连接。如果您手动创建一个页面beforeAll并在每次测试中使用相同的页面实例，这可能是一种不好的做法，视频和跟踪可能不起作用..那么这里可以做什么？
  • 用户旅程之类的测试真的很糟糕吗？我觉得它们不能与playwright文档中提到的夹具方法很好地结合起来。playwright感觉非常data-driven适合end-to-end测试 IMO的夹具。
4

0 回答 0