Cypress против Selenium WebDriver: что лучше для вас?

Как видите, здесь есть примеры команд и утверждений Cypress.

cy.visit заставит браузер перейти по указанному URL.

cy.get вернет ссылку на рассматриваемый элемент, на котором вы можете либо напечатать, щелкнуть, либо проверить утверждения об использовании содержимого и другие утверждения.

Как вы можете видеть, на первый взгляд, он удивительно похож на Selenium Webdriver, хотя и проще, и с гораздо большей мощностью.

Это только Chrome!

Cypress Test Runner работает только на Chrome. Он не поддерживает Firefox, Safari, Edge или IE. Это может стать шоком для разработчиков QA, которые привыкли к удивительной поддержке WebDriver всех этих браузеров. Но да, Cypress — это только Chrome. Существует проблема, которая была открыта для кросс-браузерной поддержки , но этой проблеме уже почти год. Приоритеты Кипариса, кажется, лежат в другом месте.

Почему веб-разработчики хотят запускать свои тесты только в Chrome? Я считаю, что есть несколько ответов на этот вопрос. Во-первых, различия между Chrome, Firefox, Safari и Edge в наши дни невелики и становятся все меньше и меньше для большинства приложений. Поэтому проверка только в Chrome, вероятно, достаточно хороша при тестировании в разработке.

Во-вторых, выполнение всех тестов во всех браузерах требует времени , и разработчики внешнего интерфейса, как мы уже говорили выше, не хотят ждать своих тестов.

В-третьих, у многих компаний есть разработчики QA, которые проводят сквозные тесты во всех браузерах, и поэтому они в порядке, так как очень редкая ошибка время от времени проскальзывает и обнаруживается командой QA. И компании, которые не имеют обширные кросс-браузерные тесты? Тогда они в порядке с теми же редкими ошибками, которые проскальзывают и доходят до пользователей время от времени.

В- четвертых, разработчики внешних интерфейсов делают уход, и хотел бы кипарис поддерживать больше браузеров, но это просто не приоритет для них, учитывая причины , описанные выше.

Это работает в браузере!

Помимо того, что разработчики веб-интерфейса привыкли к JavaScript, есть и другая причина, более техническая, что поддерживается только JavaScript.

Код, который вы пишете в своих тестовых сценариях Cypress, не запускается вне браузера, как в WebDriver. Он запускает браузер. Это то, что выполняет ваш тестовый код. Фактически, он выполняет ваш тестовый код и код приложения, которое вы тестируете!

Когда вы запускаете тест, происходит следующее: во-первых, Cypress подготовит ваш код для запуска в браузере (технически говоря, он объединит все модули в вашем коде в один файл JS с помощью веб-пакета ). Когда все будет готово, он запустит Chrome и вставит ваш тестовый код в пустую страницу. Затем он запустит этот тестовый код в браузере.

Этот тестовый код в первую очередь переходит на страницу приложения (используя `cy.navigate (‘ http: // localhost: 8080 ‘)`), которая запускается в. Cypress заставит iframe перейти на эту страницу, но ваш код работает в браузере, и (несколько волшебно) имеет доступ к тому же, что и этот iframe, и поэтому все команды, такие как «click» или «type», происходят внутри браузер, использующий обычный.

Для сравнения давайте рассмотрим архитектуру Selenium WebDriver и ее значение для выполнения тестов Selenium. Посмотрите на диаграмму ниже.

С Selenium WebDriver у вас есть три процесса:

• Selenium WebDriver
• Драйвер браузера, такой как ChromeDriver , GeckoDriver (для Firefox), EdgeDriver , SafariDriver и т. Д.
• The browser itself

All the communications between these processes means that Selenium tests take a long time to run. Which takes us to our next point:

It’s Fast!

This in-browser execution is at the basis of the speed of Cypress testing. With Cypress, you have just one process: the browser itself. With Cypress, your test code is running alongside your application code.

So an automation command (e.g., clicking a button) does not send the command to the browser like WebDriver does through out-of-process communication. Instead, Cypress uses DOM events to send a click command to the button. Much MUCH faster.

And while WebDriver’s out of process automation involves asynchronous communication, Cypress’ automation commands are mostly synchronous and in-memory. This generates extremely fast tests.

I believe that it is this speed that is the main reason that frontend developers are enamored with Cypress. WebDriver, at least perception-wise, did not give them the speed that they needed. Frontend developers want to run their tests ALL THE TIME, and cannot afford the luxury of a suite that takes tens of minutes to run. They want to run their suite, and they need it to run in a minute or two, not more.

Is this speed difference really substantial as Cypress’ documentation claims? From my admittedly small experiments, then yes, but I am not convinced that the difference is worth the other benefits WebDriver has. Try it yourself on a small sample of tests, and see for yourself!

It Has Built-In Server Mocking!

But there is another reason that Cypress is perceived as faster. Let’s remind ourselves that Cypress is meant for frontend developers. Let’s also remind ourselves that frontend developers sometimes don’t use the real backend, but rather mock the XML HttpRequests to the server. This makes for extremely fast tests, on the order of seconds, regardless of whether you use Cypress or Selenium WebDriver.

Cypress understands that, and has built-in facilities for mocking server responses, facilities that are crucial for their target audience: frontend developers. Selenium WebDriver has no facilities for that, and to mock server responses, a WebDriver tests would need to run a mock server that returns the correct responses. While possible, it is a slower and much less convenient option: a fast and in-memory facility for mocking will always outperform a slow out of process one.

And it’s not only the speed of execution. The convenience of a built-in facility for mocking servers cannot be overstated in terms of speed of writing the tests. The fact that each test explicitly describes the mock responses is much easier to code (and understand!) than a separate server program that mocks the same responses.

It Has a Bizarre Execution Model!

Yeah, I know. Weird heading for this section. But it does! Cypress’ execution model is bizarre! To prove it, let me show you some Cypress sample code:

describe(`TodoMVC using Cypress`, function () {
  it('can add todos and then delete them', () => {
    // visit the todomvc application
    cy.visit('http://todomvc.com/examples/react/#/')

    // type a new todo into the "new todo" input field.
    cy.get('.new-todo').type('Cook dinner{enter}')

    // ensure that a new todo was created correctly
    cy.get('.view > label').should('have.text', 'Cook dinner')

    // Add another todo and asser that it was added to.
    cy.get('.new-todo').type('Clean house{enter}').then(() => {debugger})

    cy.get('.view > label').eq(1).should('have.text', 'Clean house')

    // now check the toggle, to make it "done".
    cy.get('.toggle').eq(1).click()

    cy.contains('1 item left').should('exist')
  })
})

    const countItemsLeft = cy.contains('item left')

    if (countItemsLeft.innerText === '1 items left') {
      // do something...
    }

    cy.contains('item left')
      // do the following code on the element that contains "item left".
      .then(countItemsLeft => {

        // if the text in the element is "1 items left", log it.
        if (countItemsLeft.innerText === '1 items left') {
          console.log('lalala!')
        }
      })