Check out the latest test automation videos from Applitools.

We hope you got to take time to rest, unplug, and spend time with your loved ones to finish out 2022 with gratitude. I have been incredibly appreciative of the learning opportunities and personal growth that 2022 offered. In reflection of our past quarter here at Applitools, we’ve curated our latest videos from some amazing speakers. If you missed any videos while away on holiday or finishing off tasks for the year, we’ve gathered the highlights for you in one spot.

ICYMI: Back in November, Andrew Knight (a.k.a. the Automation Panda) shared the top ten Test Automation University courses.

Cypress vs. Playwright: The Rematch

One of our most popular series is Let the Code Speak, where we compare testing frameworks in real examples. In our rematch of Let the Code Speak: Cypress vs. Playwright, Andrew Knight and Filip Hric dive deeper to how Cypress and Playwright work in practical projects. Quality Engineer Beth Marshall moderates this battle of testing frameworks while Andy and Filip explore comparisons of their respective testing frameworks in the areas of developer experience, finding selectors, reporting, and more.

Automating Testing in a Component Library

Visual testing components allows teams to find bugs earlier, across a variety of browsers and viewports, by testing reused components in isolation. Software Engineering Manager David Lindley and Senior Software Engineer Ben Hudson joined us last year to detail how Vodafone introduced Applitools into its workflow to automate visual component testing. They also share the challenges and improvements they saw when automating their component testing.

When to Shift Left, Move to Centre, and Go Right in Testing

Quality isn’t limited to the end of the development process, so testing should be kept in mind long before your app is built. Quality Advocate Millan Kaul offers actionable strategies and answers to questions about how to approach testing during different development phases and when you should or shouldn’t automate. Millan also shares real examples of how to do performance and security testing.

You, Me, and Accessibility: Empathy and Human-Centered Design Thinking

Inclusive design makes it easier for your customers with your varying needs and devices are able to use your product. Accessibility Advocate and Crema Test Engineer Erin Hess talks about the principles of accessible design, how empathy empowers teams and end users, and how to make accessibility more approachable to teams that are newer to it. This webinar is helpful all team members, whether you’re a designer, developer, tester, product owner, or customer advocate.

Erin also shared a recap along with the audience poll results in a follow-up blog post.

Future of Testing October 2022

Our October Future of Testing event was full of experts from SenseIT, Studylog, Meta, This Dot, EVERSANA, EVERFI, LAB Group, and our own speakers from Applitools. We covered test automation topics across ROI measurement, accessibility, testing at scale, and more. Andrew Knight, Director of Test Automation University, concludes the event with eight testing convictions inspired by Ukiyo-e Japanese woodblock prints. Check out the full Future of Testing October 2022 event library for all of the sessions.

Skills and Strategies for New Test Managers

Being a good Test Manager is about more than just choosing the right tools for your team. EasyJet Test Manager Laveena Ramchandani shares what she has learned in her experience on how to succeed in QA leadership. Some of Laveena’s strategies include how to create a culture that values feedback and communication. This webinar is great for anyone looking to become a Test Manager or for anyone who has newly started the role.

Ensuring a Reliable Digital Experience This Black Friday

With so much data and so many combinations of state, digital shopping experiences can be challenging to test. Senior Director of Product Marketing Dan Giordano talks about how to test your eCommerce application to prioritize coverage on the most important parts of your application. He also shares some common shopper personas to help you start putting together your own user scenarios. The live demo shows how AI-powered automated visual testing can help retail businesses in the areas of visual regression testing, accessibility testing, and multi-baseline testing for A/B experiments.

Dan gave a recap and went a little deeper into eCommerce testing in a follow-up blog post.

Cypress, Playwright, Selenium, or WebdriverIO? Let the Engineers Speak!

Our popular Let the Code Speak webinar series focused primarily on differences in syntax and features, but it doesn’t really cover how these frameworks hold up in the long term. In our new Let the Engineers Speak webinar, we spoke with a panel of engineers from Mercari US, YOOBIC, Hilton, Q2, and Domino’s about how they use Cypress, Playwright, Selenium, and WebdriverIO in their day-to-day operations. Andrew Knight moderated as our panelists discussed what challenges they faced and if they ever switched from one framework to another. The webinar gives a great view into the factors that go into deciding what tool is right for the project.

Read the Let the Engineers Speak recap blog series

Let the Engineers Speak! Part 5: Audience Q&A

Articles — 01.11.2023

Let the Engineers Speak! Part 4: Changing Frameworks

Articles — 01.05.2023

Let the Engineers Speak! Part 3: Favorite Test Integrations

Articles — 12.28.2022

Let the Engineers Speak! Part 2: The Biggest Challenges

Articles — 12.22.2022

More on the way in 2023!

We’ve got even more great test automation content coming this year. Be sure to visit our upcoming events page to see what we have lined up.

Check out our on-demand video library for all of our past videos. If you have any favorite videos from this list or from 2022, you can let us know @Applitools. Happy testing!

WebdriverIO is an amazing test automation framework, and I am very excited that on December 1, 2022 WebdriverIO officially announced its version 8 release! With its previous updates in versions 6 and 7, the WebdriverIO team rewrote everything in TypeScript, removed sync support to transition to async-only, and added integration for Google Lighthouse. This version 8 release is a welcomed refinement of the framework. It shouldn’t change much for end users, nor should it have breaking changes.

With its update to version 8, WebdriverIO: 

• updated the helpful one-line command to set up a new project
• removes support for older versions of Node.js
• transitions from CommonJS to ESM
• implements a new Action API interface
• adds a new runner for Unit and Component Testing in the browser
• streamlines the way WebdriverIO deals with global objects using the test runner

Of course, the team also updated the documentation, too.

Let’s explore the WebdriverIO v8 updates.

Update to One-line Setup Command

A small but effective update so far that made me smile was being able to set up a WebdriverIO project with one command `$ npm init wdio@latest ./`. After that command, it asks you all the questions needed to set up and run your tests. It provides you with predefined options for not only end-to-end testing of web and mobile applications but unit and component testing as well.

Support for Node.js v12, v13, and v14 dropped

The Node.js team moved Node.js v14 into a maintenance Long Term Support (LTS) phase in October 2021. It is now in “maintenance” until its end-of-life in April 2023. With newer versions of Node.js available, the WebdriverIO team recommends updating to Node.js v16 or v18 directly.

Find out more about Node.js release schedule.

Transition from Common JS to EMCAScript modules (ESM)

To give some background, CommonJS and ESM refer to the module system that allows us to use code from a “next” developer/library or code/data that is in a different file. The CommonJS module system has been the default module system within the Node.js ecosystem. However, the ES module was added in Node.js v8.5.0 and has been stabilized and incorporated as standard from Node.js v13.2.0. 
You may be familiar with using `require` to use your page objects in your test files and `module.exports` or `exports` so that your page objects or other files can be accessed by your tests. This method of managing files and libraries is the CommonJS way.

With ESM you use `import` and `export` to manage files and libraries.

There are some other differences between them, but for you, the end user, this is the main one. 
This change should not affect your work as CommonJS is still supported. However, if you want to use ES modules then you can now do so. I recommend getting familiar with ESM and how it works before starting to use it. Hopefully, in the near future, there will be additional boilerplates from WebdriverIO on using ESM in your projects https://webdriver.io/docs/boilerplates/.

New Runner for Unit and Component Testing in the Browser

An exciting v8 feature is the new browser runner that allows you to run unit and component tests in an actual/real browser environment. This is going to provide you with a more realistic user interaction with your components. It comes with presets for React, Vue, Svelte, SolidJS among others, and is powered by Vite.js.

Find out more details about this new runner.

New Action Interface

This is a new interface that makes executing various actions much easier. Two new browser commands action and actions have been added. It is now much simpler and type-safe to run the right action, e.g. sending key events to the browser.

Read more about this in the WebdriverIO API docs.

WebDriver BiDi Support

WebdriverIO is based on the WebDriver protocol, which is a web standard for automating browsers. This means that, with WebdriverIO, your tests are running in a browser that your user uses rather than a browser engine. 

This WebDriver BiDi Support means that whenever new protocol changes happen in Webdriver, you as the user can use it once it’s available in browsers. 
The idea of WebDriver BiDi is to make a new standard protocol for browser automation, which will be based on the bi-directional transport protocol (WebSocket or pipes).

Optional Globals

The WebdriverIO test runner would usually register the browser object or the $ and $$ commands to the global scope. With v8 update, the user can decide if they want to continue attaching these objects and methods to the global scope or prefer importing them directly.

To import them directly you would say : 

import { browser, $, $$, expect } from ‘@wdio/globals’

Importing the $ command allows you to use it from the @wdio/globals:

Using Visual Studio Code as my code editor, if I hover over the $ it shows that it is coming as a global import from WebdriverIO:

A new configuration property called injectGlobals (defaults: true) handles whether the test runner modifies the global scope or not. If your setup works fine using global objects, no change is needed to update to v8.

You don’t have to import from @wdio/globals as it will still work.

Other Updates

Aside from these major updates, documentation has been improved and new API docs around WebdriverIO objects like browser, element, and mock have been introduced. The behavior of relative spec or exclude paths was also fixed so that now specs and exclude paths will be always seen as relative to the config file and –spec arguments, relative from the working directory.
To see all of the details of this latest release, visit the WebdriverIO blog.

Update to WebdriverIO version 8 from version 7

Install a module to help update outdated npm modules

`npm install -g npm-check-updates`

Run `ncu` to show list of outdated npm packages:

Then run `ncu -u` to upgrade your package.json:

Then finally run npm install to install new versions:

I then reran all my tests and they passed successfully.

My thoughts on the version update

WebdriverIO’s version 8 update is a continuation of work by the WebdriverIO team to make the framework more rounded and robust. I like the changes that have been made and I am looking forward to trying out unit component testing with WebdriverIO.

I love that the updates don’t have breaking changes and so this allowed me to upgrade from version 7 to 8. I would recommend that you update your project to the latest version to benefit from the updates that have been made.
If you are interested in learning more about WebdriverIO, check out my WebdriverIO course on Test Automation University. Also, check out this repo with a sample example using WebdriverIO v8.

Cypress released the first alpha version of component testing back in version 4.5.0. It caught the attention of many, but if you are like me, you didn’t understand the buzz. It’s completely okay, as component testing was always more of a domain of developers than testers. But testers can take an interest in component testing, too. Now that Cypress’ component testing features have reached General Availability (GA) in version 11, I decided to dive into this topic and find out why component testing is important. The more I played with it, the more I understood the appeal. In this blog post, I’d like to share my perspective with you.

What is a component?

Components are like Lego blocks. In the same way as toy castles, cars, and other creations can be built from Lego blocks, Web applications are built from components. Like Lego blocks, components come in different shapes and sizes and can serve different purposes. Some are used just once, some are reused all the time.

Each component has certain visual and functional properties. Like a Lego block, a component can be a common one that is used all the time and changed just slightly, or it can be a unique one that serves a specific function.

I want to show you how this works on a simple Vue.js application. Let‘s take a look at a simple Vue component that might look something like this:

<template>
 <button class=".green-button">{{ buttonText }}</button>
</template>
<script setup lang="ts">
defineProps({
 buttonText: {
   type: String,
   default: "Hello world"
 }
});
</script>

This component consists of two parts. One is the <template> part that contains a dynamic HTML markup. The second part is the <script> part that contains a TypeScript function that defines the properties that we want to render in the <template>. There is a buttonText string property that will be rendered inside the <button> element.

This is an example of a reusable component. I can use the button element all across my application, but I might want to render different texts for the button. Whenever I want to use this component, I call it like this:

<MyButton buttonText="Click me!" />

The button will render differently based on what property is passed into it. Here are some examples:

Why test a component?

If you need to make sure that this button looks good with an emoji, special character, or normal text, what do you do? You could choose an end-to-end approach by clicking through the app to find and validate all the buttons, but this is not going to be very effective. It will be slow and cumbersome.

Enter component testing.

Instead of opening the whole application, with component testing, you can just mount the component in isolation. This means that you can save time loading just the parts you are interested in and test much faster. Or you test different properties of the same component and see how they render. This can be really helpful for situations where small changes affect a big portion of the app.

Imagine you are a developer who wants to refactor a component. While you are doing so, you can get immediate feedback on anything that might be broken. In other words, it’s easier to simply render a component with an emoji than to hunt through your app looking for it.This is why component testing is growing in popularity and why it is becoming one of the major trends in front-end testing. We can already see different implementations of component testing in tools like Jest, Storybook, WebdriverIO, Playwright, and Cypress.

Buttons don’t seem like much, though…

You are right. This example is way too simple to show the value of component testing.

Instead of a button, imagine a login form that validates a multitude of different inputs. How do you test that the form throws correct errors?

You could write an end-to-end test that will load the login screen, enter valid (or invalid) credentials, validate error messages, log in, log out, etc.

Or, instead, you could open the login form component only and try different inputs without the need of logging in or loading the rest of the login page. Loading a single component is way faster than loading the whole application. Testing a component in isolation can provide a lot of value, especially in cases like these.

What makes component testing with Cypress great

The main difference between Cypress and other tools is that it runs its component tests in a real browser. Besides that, you have all the power of the Cypress API at hand for your component tests as well. You can click, type, make assertions, and intercept network calls. You can spy on functions or stub them. This enables you to get to some really hard-to-reach places in your app and test them. You can mock your data or the component state, avoiding difficult data management or app setup.

Setting up component testing in Cypress

Starting with Cypress v10, setting up component testing is very straightforward.Once you open Cypress GUI using the npx cypress open command, you will be welcomed by this screen:

The component testing option will take you through a simple setup wizard that will help you set up everything according to your application’s needs. As opposed to end-to-end testing, component testing is actually framework-specific. While the principles are pretty much the same for all frameworks, the loaders differ slightly – each one of them needs a separate set of tools. The setup wizard will take you through the steps to set up everything.

Framework and bundler

On the very next screen, Cypress asks you to choose a framework and a bundler. It even tries to detect the ones used in your app automatically. If you are building web applications for living, you are probably familiar with the different choices.

As a tester, I needed to become familiar with these terms, especially with the “bundler”. The bundler is an essential part in building a modern web application. It converts the code you write into something a browser can read. As mentioned earlier, components split our application into small “Lego blocks”. These are often .vue files, .jsx files, or something similar. But these will not work in browsers by themselves. The bundler makes them into a bunch of .html, .js, and .css files that browsers can read.

When running a component test, Cypress will use the bundler to convert your component file into something a browser can read using the same bundler as your application does.

Cypress component testing project

Based on the inputs, the installation wizard will set up our project. Looking at the cypress.config.ts file, you can see that the configuration is actually pretty concise:

export default defineConfig({
 component: {
   devServer: {
     framework: "vue",
     bundler: "vite",
   },
 },
});

By default, Cypress will take options set in vite.config.ts file in our project, so anything we have set up for our app will instantly become available to Cypress tests as well.

cy.mount()

Besides resolving our configuration, Cypress will create a couple of helper files, one of the most important being component.ts located in the cypress/support folder.

import { mount } from 'cypress/vue'
 
// Augment the Cypress namespace to include type definitions for
// your custom command.
// Alternatively, can be defined in cypress/support/component.d.ts
// with a <reference path="./component" /> at the top of your spec.
declare global {
 namespace Cypress {
   interface Chainable {
     mount: typeof mount
   }
 }
}
 
Cypress.Commands.add('mount', mount)
 
// Example use:
// cy.mount(MyComponent)

This file will contain the mounting function for the framework you use. Cypress supports React, Angular, Svelte, Vue, and even frameworks like Next.js and Nuxt. As of Cypress version 11, most of these are out of beta.

How Cypress is built

Cypress’ architecture is unique when compared to other testing tools. With Playwright or Selenium, the goal is to automate a browser in order to perform some actions. With Cypress, you are essentially building an app to test your app.

When you are developing an application, your files get bundled and opened inside a browser. Imagine your standard npm run dev mode.

With Cypress, pretty much the same principle is applied. Your test files get bundled and opened in a browser. With component testing, instead of opening the app for your end-to-end test, you’ll mount your component. Pretty cool, if you ask me.

Creating a first component test

Once you set up your component testing configuration and your cy.mount() command, you are ready to start testing! So, let’s take a look at how this can be done.

With end-to-end testing, we usually have a dedicated folder where all our tests are. But with component testing, it is better to place your tests right next to your components.

When you create your first test, put a standard naming convention in place. In fact, Cypress will encourage you to do so with its default configuration, as it will look for any .cy.js or .cy.ts files. Basically, the .cy addition identifies the file as a Cypress test

You can, however, change this to .spec.ts in your configuration file:

component: {
 devServer: {
   framework: 'vue',
   bundler: 'vite',
 },
 setupNodeEvents(on, config) { },
 specPattern: 'src/**/*.spec.ts',
}

Mounting the component

Let’s now try to test our button component from before. Component testing in Cypress feels very familiar with end-to-end testing. It uses the same it() and describe() blocks from Mocha, but instead of calling cy.visit(), you will use cy.mount() to mount your component into the browser.

import SaveButton from './SaveButton.vue'
 
it('display save button', () => {
 
 cy.mount(SaveButton)
 
})

Notice that whenever we want to mount a component, we need to import it into our test file. When we run this test in Cypress, it will successfully mount our component.

You’d be right to raise your eyebrows, as this is not exactly what you would expect. Our component is missing CSS styles! In many cases, components rely on some other resource. It can be a module, package, state manager, or CSS as in this case. This means that in order to make our component test work, it is often the case that we need to import a bunch of stuff.

CSS is something that probably all your components will need, so you might want to import that to your component.ts configuration file. This is a place to set a global configuration for mounting all of our components.

import { mount } from 'cypress/vue'
import '@/index.css';
 
declare global {
 namespace Cypress {
   interface Chainable {
     mount: typeof mount
   }
 }
}
 
Cypress.Commands.add('mount', mount)

Passing properties

Let’s now try something else with our component. You may remember that we were defining a buttonText property that would then render text in our button. We can pass our own properties to the button right within the test by giving our cy.mount() function a props object with given properties:

import SaveButton from './SaveButton.vue'
 
it('SaveButton component', () => {
 
 cy.mount(SaveButton, {
   props: {
     buttonText: 'Hello world'
   }
 })
 
})

Easy, right? We are now ready to test different versions of the button that may appear in our application. And since we are in a Cypress test, we can use Cypress commands, too. For example, we can check that the buttonText property is actually rendered in our button:

import SaveButton from './SaveButton.vue'
 
it('SaveButton component', () => {
 
 const buttonText = 'Hello world'
 
 cy.mount(SaveButton, {
   props: {
     buttonText
   }
 })
 
 cy.get('button').should('have.text', buttonText)
 
})

Component testing and its importance

Component testing enables you to look at the individual components of your application and ensures that they are working as expected. It helps testers and developers identify and fix issues with individual components before they become bigger problems affecting the whole application.

While component testing still falls mainly in the developers’ area of expertise, understanding this type of testing is beneficial for testers as well. Most notably, learning how web applications are built improves intuition for finding serious bugs.

To learn more about component testing in Cypress, check out the Getting Started with Component Testing in Cypress on-demand webinar. Head over to the Applitools design team solution page to learn how Applitools speeds up component testing with AI.