Cypress – The end of WebDriver?

End-to-end testing. It’s likely most testers least favourite part of their job, and likely a task that most developers actively hate. Flaky, brittle tests, tools that fail to provide consistent results, stakeholders insisting on a ‘test all the things’ approach (that’s for another post later).

Hands up any tester reading this who has had their patience tested more than their intended subject-under-test? Any of you felt like tearing your hair out when your test-suite reports a sea of red awfulness instead of that pleasing glow of green? How many times has the result been different failures on the same release candidate?

Now, how many of you have experienced the above because of a reliance on Selenium?

Me too. In the past, we had to install Selenium server, then choose a wrapper like WebDriver, Nightwatch or Protractor etc, then choose a framework like Mocha or QUnit and so on, then choose an assertion library like Chai or expect.js etc, and any other additional libraries like Sinon or whatever.

We then had to write tests using a tool that sits outside the browser, asking it questions via remote commands sent over the network, and interpreting the response. Often, we would have to deal with silly situations such as Selenium being unable to click on an element, because another element sits on top of it. Or we would have to hack around with things like explicit waits, or worse – you wouldn’t believe the number of ‘thread.sleep()’ statements I’ve seen over the years, all because execution runs were wholly unpredictable.

For years I would hear testers say “oh we use Selenium… it’s flaky, but there’s really nothing else”. Well now there is. Cypress.io, and it doesn’t use Selenium.

Cypress is different because it’s an all-in-one testing framework, assertion library, mocking and stubbing mechanism. There are no language or driver bindings – it is just JavaScript. And most importantly perhaps – it runs in the same run-loop as your application, meaning it can see and test anything that runs inside the browser. It is built to perform well with modern JavaScript frameworks.

Most crucially for project delivery – in my experience, developers love it. This has meant they fully invest in the creation of end-to-end tests and that means Devs and QA’s can truly integrate and reduce time and effort, adding value to the business instead of creating artificial bottlenecks and hand-overs. And all this before I even mention the increased consistency and reliability of the test-suites I’ve seen migrated from WebDriver to Cypress.io.

Whether it truly is the end of WebDriver is another matter. The contributors of Cypress.io have for example, explicitly stated that they will never support native. They do intend to support hybrid mobile apps – in fact you can already use Cypress for testing hybrid mobile apps in the Ionic framework for example – but not native. So if you need a tool for testing native apps, you will probably brush aside the 10 or so alternatives to Appium and use that – which exposes the WebDriver API. So no, WebDriver isn’t going away, but if you need a tool for your web-app end-to-end tests and want your developers to really buy into the process – pick up Cypress.io and put that in your toolbox – you won’t be sorry.

So, how does it work then?

Cypress consists of an open-source test runner and a dashboard. As mentioned, Cypress runs in the same run-loop as your web-app. This is possible because there is a Node.js process performing the role of a server, talking to Cypress all the time. This enables synchronicity and real-time responses to your applications events. Cypress can also intercept and modify network traffic as it operates at the network layer. It can also dip into the operating system. Wanna take a screenshot? Record video? Manage file systems? No problem.

Cypress has access to every object, from the window, document, down to every DOM element. This is achieved without object serialisation or over-the-wire protocol, and without having to add sleeps or waits in your code. It allows full capability to spy, mock and stub.

Crucial to investigating failures – Cypress has excellent debugging capabilities, which due to the architecture of Cypress, allows you to click back through the test execution like a time-traveller picking through the minute details of exactly what happened, as if you were manually replaying the automated test – well, because you are!

A simple example:

Cypress is easy to install. All you need to do is: ‘npm install cypress –save-dev’ and it will be installed as a dev dependency in your project.

You can then open it with npx (if you’re using npm > 5.2): ‘npx cypress open’.

You will see the Cypress Test Runner open. For ease of use, you should add a script to your package.json:

{

    "scripts": {

        "cypress:open": "cypress open"

    }

}

this allows you to open Cypress from your project route with: ‘npm run cypress:open’.

Next, write a simple test. Create a file in the ‘cypress/integration’ folder that Cypress created for us, called ‘sample_spec.js’. As soon as it is created, the Cypress Test Runner will display it. That’s because Cypress is monitoring your spec files for any changes.

Even though we have no actual test code in our new file, Cypress can still run it and it will open the browser. To do this, simply click the spec file name in the Test Runner.

Now write the following code into the spec file:

describe('A noddy little test', function() {

    it('should pass', function() {

        expect(true).to.equal(true);

    })

})

once you save this file, you should see the browser reload and the dashboard report a pass.

A meatier example

import { login, homepage } from '../../../page-objects';

describe('A site member wants to log in', () => {
    const memberName = "myname01';

    beforeEach(() => {
        cy.server();
        cy.visit("https://mymadeupsite/");
    }

    describe('when they go to the home page', () => {
        it('should display the login button', () => {
            homepage.getLogin().should('be.visible');
        });
    });

    describe('when they click login', () => {
        it('should take them to the login screen', () => {
            homepage.goToLogin();
            login.loginForm().should('be.visible');
        });
    });
});

There you go. A small start but here we have a test runner, a framework, a debugger, a dashboard, dev dependency, script, and test – it took about 3 minutes. Can you do that using Selenium?

Source: https://www.cypress.io/