COVID-19 has drastically affected the global workforce. Suddenly, development teams everywhere are now working from the safety of their homes. Many new remote workers are finding it challenging to effectively collaborate with their teammates. Fortunately, Applitools offers several features that make collaboration a breeze!

Remarks

All Applitools test results include images of your application, which makes for easier collaboration. As the old saying goes “a picture is worth a thousand words”. Not only can all team members view the screenshots from tests results, but they can also add remarks to the images. These remarks can be reviewed and also serve as a discussion thread right at the point of question.

Bug Regions

Team members can also indicate which parts of their application’s screenshot contains bugs. Similar to Remarks, users can highlight certain areas of the image and leave comments about that area. By specifying it as a Bug Region, users can also fail the test and optionally snooze failures for this bug in future runs! This eliminates the need for back and forth questions between the bug reporter and the assignee – as details regarding the bug are overlaid on top of the bug itself.

Root Cause Analysis

In addition to the image itself, Applitools also provides root cause analysis to determine the exact cause of the bug! While the image alone helps teams quickly identify issues with their application, the root cause analysis features provides a fast and simple way to determine what HTML or CSS changed to cause this issue. Utilizing this feature helps teams collaborate more effectively as well as move quicker to result bugs.

Jira

Applitools integrates nicely with Jira to allow you to associate your visual testing results with Jira tickets for better tracking. After integrating these two tools, the Applitools Bug Region modal now includes an option to create a new Jira issue. Once the issue is created, additional options are available in the Bug Region modal such as viewing the bug in Jira and linking to more Jira issues.

Slack Notifications

There is also an Applitools plugin available for Slack. By enabling this plugin for your Slack workspace, your team will automatically be notified of your test results. You can choose whether to receive slack notifications every time an Applitools batch completes, or only when there are failures. This provides another mechanism for fast feedback in the place where your teams already collaborate.

Working remotely doesn’t have to negatively impact team collaboration. Tap into the hidden features of some of your favorite tools, like Applitools,  for fast and effective remote work.

The post 5 Visual Testing Features that Foster Collaboration Between Remote Workers appeared first on Automated Visual Testing | Applitools.

At one point in time, the server-side code was responsible for generating and serving every page in our application. Nowadays, Single Page Apps (SPA) are taking a bigger slice of the pie, as more clients are leaning towards building their applications as an SPA.

Developers spend most of their time debugging a SPA inside the browser, by debugging the JavaScript files, CSS styles and the DOM, hoping to find the root cause of any visual bug appearing in their application.

Applitools realizes the complexity of visually debugging an application and introduced the Root Cause Analysis (RCA) module on their Test Manager Dashboard to help quickly identify the root cause behind visual UI changes.

In this article, I will demonstrate the Applitools RCA feature by walking you through a complete step by step guide to visually test a Vue.js app with Storybook and Applitools.

If you’re not already familiar, Applitools is an automated visual regression testing framework. It focuses on the visual aspects of your app and plays a major role in exposing the visual differences between baseline snapshots and both current and future snapshots.

Applitools integrates with dozens of development and testing frameworks, such as Cypress.io, Storybook and Selenium. It provides SDKs for use in your projects to seamlessly communicate and interact with Applitools, in order to send both baseline and test screenshots.

So, get started with visual UI testing. Your visual testing project will depend on React, Storybook and Applitools. You will also need the node.js tools. So, firstly, make sure you know the following software tools and install on your machine:

• Git
• Node.js and npm
• Vue.js
• Storybook
• Applitools

Before we immerse ourselves in writing code, let’s look at how Applitools and Storybook work together.

How Applitools Works With Storybook

Whether you use Vue.js, React or Angular, Storybook doesn’t offer any extension points for third-party frameworks, such as Applitools, to integrate with. The Applitools team worked around this limitation by providing the Applitools Eyes Storybook SDK.

Once installed, this SDK collects all stories in the application, runs them all via the Storybook engine, generates DOM snapshots for each story and uploads these snapshots to the Applitools Eyes server. Here’s a visual of this flow:

The Applitools server runs the tests generates image snapshots. Applitools compares each snapshot to a baseline snapshot (if one exists) and displays the results on the Test Manager Dashboard.

This kind of integration provides a smooth experience in terms of writing Storybook stories. Nothing changes in the way you write your Vue.js apps.

Automated Root Cause Analysis

The concept of Root Cause Analysis stems from the world of management, where it’s defined as a method of problem solving, used for identifying the root causes of faults or problems.

So far, Applitools has been focusing on visual testing by comparing the baseline and the current test run snapshot through their AI engine. It finds the visual differences in order to map them graphically. Previously, there was no way to search your codebase for a reason behind any visual testing bug. As you may know, searching through code is nightmarish, time-consuming and tedious!

This is where Applitools steps in with RCA, showing you the exact DOM and CSS changes between the baseline snapshot and the current test run snapshot.

Why is this so important for both developers and QA testers? Let’s take a look.

Step By Step Guide

For this demonstration of visual testing a Vue.js application with Storybook and Applitools, I’ve chosen the Bootstrap Vue open-source library hosted on GitHub under this repo. This library, with over 40 plugins and more than 75 custom components, provides one of the most comprehensive implementations of Bootstrap v4 components and grid system for Vue.js. With extensive and automated WAI-ARIA accessibility markup.

The plan is to start by installing Storybook onto the Bootstrap Vue project. Write and run a few Storybook stories, install the Applitools Eyes SDK for Storybook and finally demonstrate the RCA feature.

Now, let’s get on with it and start coding …

Step 1: Clone the Bootstrap Vue GitHub repo locally on your machine by running this command:

git clone git@github.com:bootstrap-vue/bootstrap-vue.git

Step 2: Install all NPM package dependencies by running this command:

yarn

Step 3: Install the Storybook NPM package as a dev-dependency by issuing this command:

yarn add @storybook/vue -D

Step 4: Install all peer dependencies required by Storybook to function properly by issuing this command:

yarn add vue-loader babel-loader babel-preset-vue -D

Step 5: Install css-related NPM packages in order to load CSS styles inside your Storybook stories by issuing this command:

yarn add css-loader style-loader -D

Step 6: Add the following NPM script to your package.json file in order to start the Storybook:

{

  "scripts": {

    "storybook": "start-storybook"

  }

}

Step 7: Create the Storybook config.js file inside a .storybook folder located at the root of the solution folder as follows:

import { configure } from '@storybook/vue';

function loadStories() {

  const req = require.context('../stories', true, /\.stories\.js$/);

  req.keys().forEach(filename => req(filename));

}

configure(loadStories, module);

Step 8: Create a scss-loader.scss file inside the .storybook folder to include all the styles required by Bootstrap Vue library components to load properly inside our Storybook stories:

@import ‘../node_modules/bootstrap/scss/bootstrap.scss’

@import ‘../src/index.scss’

Then import this file inside the config.js file as follows:

import { configure } from '@storybook/vue';

import ‘!style-loader!css-loader!sass-loader!./scss-loader.scss’

function loadStories() {

  const req = require.context('../stories', true, /\.stories\.js$/);

  req.keys().forEach(filename => req(filename));

}

Step 9: Create the navbar.stories.js file inside the stories folder, located at the root of the solution folder, to hold our Storybook stories for the NavBar component:

import { storiesOf } from '@storybook/vue'

const navbarStories = storiesOf('BNavBar', module)

navbarStories.add('Full Navbar', () => ({

  template: `<div>

  <b-navbar toggleable="lg" type="dark" variant="info">

    <b-navbar-brand href="#">NavBar</b-navbar-brand>

    <b-navbar-toggle target="nav-collapse"></b-navbar-toggle>

    <b-collapse id="nav-collapse" is-nav>

      <b-navbar-nav>

        <b-nav-item href="#"><span>Link</span></b-nav-item>

        <b-nav-item href="#" disabled>Disabled</b-nav-item>

      </b-navbar-nav>

      <b-navbar-nav class="ml-auto">

        <b-nav-form>

          <b-form-input size="sm" class="mr-sm-2" placeholder="Search"></b-form-input>

          <b-button size="sm" class="my-2 my-sm-0" type="submit">Search</b-button>

        </b-nav-form>

        <b-nav-item-dropdown text="Lang" right>

          <b-dropdown-item href="#">EN</b-dropdown-item>

          <b-dropdown-item href="#">ES</b-dropdown-item>

          <b-dropdown-item href="#">RU</b-dropdown-item>

          <b-dropdown-item href="#">FA</b-dropdown-item>

        </b-nav-item-dropdown>

        <b-nav-item-dropdown right>

          <template slot="button-content"><em>User</em></template>

          <b-dropdown-item href="#">Profile</b-dropdown-item>

          <b-dropdown-item href="#">Sign Out</b-dropdown-item>

        </b-nav-item-dropdown>

      </b-navbar-nav>

    </b-collapse>

  </b-navbar>

</div>`

}))

The story groups all NavBar stories under the name BNavBar and assigns the first story the name of Full Navbar.

There are two ways to tell Storybook stories about your Vue.js components. Either define all used components in a components object property on the story itself or define the components globally inside .storybook/config.js file so that they are available to all running stories in your solution.

Let’s follow the latter option and define all components needed by NavBar story inside .storybook/config.js file using the Vue.component() helper method:

import { configure } from '@storybook/vue'

import Vue from 'vue'

import '!style-loader!css-loader!sass-loader!./scss-loader.scss'

import {

  BNavbar,

  BNavbarNav,

  BNavbarBrand,

  BNavbarToggle,

  BButton,

  BCollapse,

  BNavItem,

  BFormInput,

  BNavForm,

  BNavItemDropdown,

  BDropdownItem

} from '../src'

Vue.component('b-navbar', BNavbar)

Vue.component('b-navbar-nav', BNavbarNav)

Vue.component('b-navbar-brand', BNavbarBrand)

Vue.component('b-navbar-toggle', BNavbarToggle)

Vue.component('b-button', BButton)

Vue.component('b-collapse', BCollapse)

Vue.component('b-nav-item', BNavItem)

Vue.component('b-form-input', BFormInput)

Vue.component('b-nav-form', BNavForm)

Vue.component('b-nav-item-dropdown', BNavItemDropdown)

Vue.component('b-dropdown-item', BDropdownItem)

function loadStories() {

  const req = require.context('../stories', true, /\.stories\.js$/)

  req.keys().forEach(filename => req(filename))

}

configure(loadStories, module)

Step 10: Now the story is ready, let’s run it with Storybook using this command:

yarn storybook

The Storybook engine runs successfully and renders our Navbar story.

Now let’s install the Applitools Eyes SDK for Storybook.

Step 11: Install the Applitools Eyes SDK for Storybook NPM package as a dev-dependency by issuing this command:

yarn add @applitools/eyes-storybook -D

In order to authenticate via the Applitools server, you need to supply the Eyes-Storybook SDK with the API key you got from Applitools. Read more about how to obtain the API key here.

To do this, set the environment variable APPLITOOLS_API_KEY to the API key before running your tests. For example, on Linux/Mac:

export APPLITOOLS_API_KEY=<your_key>

And on Windows:

set APPLITOOLS_API_KEY=<your_key>

Step 12: Let’s run the first cycle of the visual UI testing by issuing this command:

npx eyes-storybook

Once the tests are done running, let’s check back with the Applitools Test Manager Dashboard and verify the results.

The left side of the Dashboard lists all batch test runs that you have previously performed. Currently, there is a single test run with a status of Passed. This is the first test run and so Applitools engine automatically passes this test and all snapshots thereafter as baseline snapshots.

Click on the single batch test to view the snapshots available. For each and every Storybook story, a snapshot is generated by Applitools.

Expand the BNavBar: Full Navbar test run and click the snapshot to view it in a bigger scale:

As you can tell, the test run snapshot is simply an image snapshot for the story that runs inside the Storybook playground application.

At this moment of time, Applitools stores all the generated snapshots as baseline snapshots. The future test runs would generate a new set of snapshots and Applitools would compare them to the baseline ones and report the results accordingly.

You have noticed that Applitools Eyes SDK for Storybook is prepackaged with some default settings allowing you to do visual testing for your stories without having to specify any test configuration settings. However, that doesn’t mean that Applitools doesn’t offer you the means to customize your tests by specifying test configuration settings either through environment variables or storing your settings inside the applitools.config.js configuration file.

Let’s switch gears and explore a unique gem of Applitools that is the Regression UI testing. The traditional regression testing verifies recent source code changes or additions and that the functionality of the software has not changed or been affected in any way.

Applitools allows you to perform visual UI Regression testing. You can run multiple cycles of test runs and all visual changes collected from one to another, are detected by Applitools servers and logged into the Dashboard.

Step 13: Let’s introduce a visual change in the Navbar component by including the following CSS selector inside .storybook/scss-loader.scss file and run our tests again.

@import "../node_modules/bootstrap/scss/bootstrap.scss";

@import "../src/index.scss";

a {

  background-color: yellow;

}

The change causes all the hyperlinks on the Navbar component to render with a background color of yellow.

Step 14: Let’s run the second cycle of the visual UI testing by issuing this command:

npx eyes-storybook

Notice the logs on the terminal windows after running the command:

The test failed and that’s exactly what we expect. Applitools detected the change we introduced to the background color of the hyperlinks and reported it.

Let’s switch back to the Applitools Test Manager Dashboard to check the results.

The new test run is marked as Unresolved. Expand on the Navbar test run to view the visual differences highlighted to you by Applitools:

Make sure both snapshots are selected so that you can easily view the differences. If not, locate the following menu and choose the option Both:

The snapshot above highlights all the hyperlinks, indicating that those hyperlinks have changed.

Step 15: Click on the RCA tool icon (highlighted in the red rectangle) to get a full analysis of the source of this visual bug.

Next, you select the visual difference you want RCA to assess.

I’ve selected to click on the Lang hyperlink on the Navbar. Notice how the RCA tool detects a css style change on the <a> tag represented by the Yellow background.

The RCA tool runs and shows the root cause of this visual difference, which is a change in the CSS Rules.

Step 16: The RCA tool can also detect Attribute changes. Let’s change the tag of the Search box to have a size of lg as follows and run the test once more.

<b-form-input size="lg" class="mr-sm-2" placeholder="Search"></b-form-input>

The RCA tool detects a change in the attributes of the Search box.

It also shows the change of CSS rules as follows:

Step 17: Another category RCA detects is the DOM changes category. Let’s wrap the Search button text with a paragraph tag as follows and run the test again:

<b-button size="sm" class="my-2 my-sm-0" type="submit"><p>Search</p></b-button>

The RCA tool detects a change in the text inside the Search button. Instead of rendering the text as is, the new test snapshot renders the text inside a <p> tag.

Any test run with status Unresolved requires someone’s attention and manual intervention to accept or reject the change. In this case, you may accept the new change(s) and thus update the baseline snapshots.

On the other hand, if the change detected is undesirable, then this implies a bug in the source code and you can reject this new test run to keep the original baseline snapshot without any changes.

In Conclusion

Applitools RCA is both powerful and convenient. It can pinpoint the exact DOM/CSS change. If you did not intend the change, you can identify the code the responsible code quickly and make appropriate modifications to pass your tests.

RCA supports a set of DOM/CSS categories of change, including:

• Textual changes
• CSS Property changes
• Attributes changes
• Bounding Box changes
• Tag changes (for example, when you replace a button with a hyperlink)

Happy Testing!

Video Demonstration

More about Applitools

• Request a demo of Applitools.
• Sign up for a free Applitools account.
• Check out our tutorials.

The post Vue.js Development with Storybook and Applitools appeared first on Automated Visual Testing | Applitools.

I’ve been playing around with Applitools for quite some time now, and I’d like to share what I’ve found to help you quickly troubleshoot React bugs and fix them fast.

My most recent articles in this series showed you how to integrate Applitools with Angular and Storybook. In case you missed these, you can find them here:

• Applitools – The automated visual regression testing framework

• Mixing Storybook with Angular with a sprinkle of Applitools

If you’re not already familiar, Applitools is an automated visual regression testing framework. It focuses on the visual aspects of your app — as opposed to functional testing — and plays a major role in exposing the visual differences between baseline snapshots and both current and future snapshots.

Applitools integrates with dozens of testing frameworks, such as Cypress.io, Storybook, and Selenium. It provides SDKs for use in your projects to seamlessly communicate and interact with Applitools, to send both baseline and test screenshots.

This article delves into a great new feature offered by Applitools: Automated Root Cause Analysis (RCA). The demo section will use a ReactJS app, together with Cypress.io, to demonstrate the RCA feature and its application.

Disclaimer: The main goal of this article is simply to introduce you to the Applitools RCA feature. If you are looking for an in-depth tutorial on the topics mentioned in this article, I recommend the following links:

• React JS
• Cypress.io
• Applitools
• Applitools RCA

Automated Root Cause Analysis

The concept of Root Cause Analysis stems from the world of management, where it’s defined as a method of problem-solving used for identifying the root causes of faults or problems.

So far, Applitools has been focusing on visual testing by comparing the baseline and the current test run snapshot through their AI engine. It finds the visual differences in order to map them graphically. There was previously no way to search your codebase for a reason behind any visual testing bug. As you may know, searching through code is nightmarish, time-consuming, and tedious!

This is where Applitools steps in with RCA, showing you the exact DOM and CSS changes between the baseline snapshot and the current test run snapshot.

Why is this so important for both developers and QA testers? Let’s take a look.

Demo

I’ll demonstrate the RCA feature using the Calculator project, previously published as part of the example projects on the React JS website.

Next, we’ll follow these steps to run the Calculator and add a few Cypress test cases.

Step 1: Clone the repository locally by issuing the following git command:

git clone git@github.com:ahfarmer/calculator.git

Step 2: Install all the npm dependencies by issuing the following command:

npm install

Step 3: Run the app:

npm run start

And you should see something like this:

Voila. It works!

Step 4: Add Cypress package to the project:

npm install --save-dev cypress

The Cypress npm package adds a set of test files to help you with writing your own automated tests.

Step 5: Run the Cypress tests available now in the project by issuing the npx Cypress CLI command:

npx cypress run

Now that Cypress is running properly, let’s add the Applitools Eyes SDK for Cypress package.

Step 6: Add the Applitools Eyes Cypress SDK package to the project:

npm install @applitools/eyes.cypress --save-dev

The Applitools Eyes Cypress SDK is a simple Cypress plugin. Once installed, it adds a few commands to the main cy object.

More specifically, it adds three main methods: cy.eyesOpen to start the test, cy.eyesCheckWindow to take screenshots (for each test step), and cy.eyesClose to close the test.

Let’s write our first Cypress test case to simulate adding two numbers and validating the result of the addition operation.

Step 7: Inside the cypress\integration folder, create the addition.spec.js file and paste the following:

View the code on Gist.

The spec file is self-explanatory. However, there’s one thing to note here. In terms of the selectors used inside cy.get() methods, the Calculator app never uses any ID or Class to distinguish buttons.

I used a nice feature offered by Google Chrome DevTools to copy the selector of the buttons I am interested in.

To do so yourself, simply follow these steps:

1. Right-click on the button.
2. Select “Inspect.” Chrome’s DevTools opens on the Elements tab with the element highlighted in blue.
3. Right-click the highlighted element.
4. Select “Copy” > “Copy selector.”

Next, let’s run the spec file to make sure our test runs successfully.

Step 8: Run the spec file:

npx cypress run --spec="cypress\integration\operations\addition.spec.js"

Now that our spec file runs successfully, let’s make use of the Applitools Eyes Cypress SDK commands to capture a few snapshots.

Step 9: Add the Applitools Eyes Cypress SDK commands to the addition.spec.js file:

View the code on Gist.

The code is self-documented.

Now, to integrate Applitools Eyes Cypress SDK into a spec file, you follow the Workflow below:

Start a new test

cy.eyesOpen({
    appName: '...',
    testName: '...',
    browser: { ... },
});

Take a snapshot (You may repeat this step wherever you want to take a snapshot)

cy.eyesCheckWindow('...');

End the test

cy.eyesClose();

Step 10: Run the spec file:

npx cypress run --spec="cypress\integration\operations\addition.spec.js"

Step 11: Check the test run in Applitools Test Manager.

Notice the Add two numbers test run on the grid. Clicking this test run opens the three snapshots that were taken when we ran the Cypress spec file.

The first snapshot is labeled “Number 8 clicked.”The image shows the number 8 in the display of the calculator.

The second snapshot is labeled “Number 7 clicked.” This one shows the number 7 in the display.

Finally, the third snapshot is labeled “Display value of 15.” The image shows the number 15 in the display of the calculator.

Since this is the first test run, Applitools will save these as the baseline images.

Next, we will simulate a visual difference by changing a CSS selector and letting Applitools detect this change. Then, we’ll run the test again and see the results.

Step 12: Let’s assume that the CSS selectors were changed and caused a change in the background of the Number 8 button. Add the following CSS selector to Button.css file as follows:

div.component-button-panel > div:nth-child(2) > div:nth-child(2) > button {
  background-color: #eee;
}

Ready? Let’s run the spec file once again.

Step 13: Run the spec file. The test case fails, as expected, and Applitools detects a background color change for the Number 8 button.

npx cypress run --spec="cypress\integration\operations\addition.spec.js"

Notice how the Applitools Test Manager recorded the second run of the test case and highlighted the visual difference in the three snapshots.

Step 14: Click on the first snapshot and compare to the baseline.

Applitools Test Manager displays both the baseline snapshot and the current test case run. Also, the number 8 button is highlighted to signala visual difference.

Step 15: Click on the RCA tool icon (highlighted in the red rectangle) to get a full analysis of the source of this visual bug.

Next, you will be asked to select the visual difference you want the RCA to assess.

The RCA tool runs and shows the root cause of this visual difference, which is a change in the CSS Rules.

The RCA tool can also detect DOM changes. Simply use the RCA Pointer Tool to select two buttons: 7 on the baseline (left side) and 5 on the current test run snapshot (right side). The results are in the image below.

In the Text content, the RCA shows the difference between the two buttons. It also gives details about the bounding box for each button and the position.

Let’s change other DOM attributes and run the test again.

Step 16: Next, locate the src/component/Button.js file and add a class=”btn” to the HTML button:

<div className={className.join(" ").trim()}>
   <button class="btn" onClick={this.handleClick}>{this.props.name}
   </button>
</div>

Now, let’s run the test and check the results.

Step 17: Run the spec file. The test case fails, and Applitools detects a change in attributes for the buttons used to form the Calculator.

npx cypress run --spec="cypress\integration\operations\addition.spec.js"

Another category RCA detects is the Attributes category. It shows that in the current test run, each button has a new class attribute set.

Applitools RCA is both powerful and convenient: It can pinpoint out the exact DOM/CSS change. Then, all you have to do is locate the codebase and do whatever is required to pass your tests.

Remember that you can always accept the current test run and update the baseline, or reject the test run and keep the existing baseline snapshot.

RCA supports a set of DOM/CSS categories of change, including:

• Textual changes
• CSS Property changes
• Attributes changes
• Bounding Box changes
• Tag changes (When an entire Tag gets changed from one test run to another. For instance, when a button is replaced by a hyperlink.)

Conclusion

The advent of Applitools RCA is a game-changer! Not only can you use Applitools for validating visual differences in your web app, but you can also make use of RCA to go in-depth and find the exact source of a visual difference bug with ease and minimal effort.

Happy Testing!

How much time will you save with Root Cause Analysis? Let us know in the comments.

The post How to troubleshoot and fix React bugs fast [step-by-step tutorial] appeared first on Automated Visual Testing | Applitools.