Protractor, the Angular end-to-end testing tool, is officially being sunset. With development ending at the end of 2022, we need to assess what our options are for further investing in Protractor as the tool that maintains our end-to-end testing suite. Here, we’ll take a look what our top Protractor alternatives are moving forward and how we can stay confident in our tests.

Why is Protractor being deprecated?

The Protractor GitHub issue that announces the deprecation plans goes into a lot of detail about why the decision was made and how it was not made lightly, but the theme of the decision is that the JavaScript ecosystem was in a completely different state back in 2013 when Protractor was created.

WebDriver APIs weren’t standard and this was before popular end-to-end tools like Cypress and Playwright existed.

Fast forward to 2021, where developers have a wide variety of options for their end-to-end tests, giving teams a way to make sure their needs are met for their individual use cases.

The Protractor team inside Google ultimately made a decision weighing the cost of updating Protractor and what that migration effort would look like for users, where it made more sense to help guide those users to other solutions.

What are our options moving forward for Protractor alternatives?

Luckily there are a lot of great testing tools with ample documentation that should make the transition smooth.

To get a sense of what tools we can use, we’ll look at some of the popular options we can use along with a basic example of a test with that particular tool.

We’ll start with this example of a test inside of Protractor:

Inside of this test, we’re loading up The Kitchen’s Select ingredient where we select an item (garlic) from that dropdown and make sure it successfully has that value.

So now, let’s dive into what other frameworks we have available as alternatives to Protractor.

Cypress

Cypress is a tool that has become very popular in the JavaScript world. Cypress has an API much like Playwright and Puppeteer which we’ll see shortly, but it goes an extra step to try to make the experience of writing and running tests better.

For one, unlike the others, Cypress ships with an assertion library out of the box (Chai). While it’s a small thing, it’s one less piece to configure.

Cypress additionally has a testing UI that pops up when running tests locally, giving flexibility to run only the tests you want and see the results along with debugging options in realtime.

The first thing we’ll notice is the code is short and concise.

Here we visit the page, which includes both launching a browser and navigating to the page. Then, in one line, we can get our Select dropdown, select our option, and check that it has the value we need.

While some of the other tools might have more flexibility, the Cypress API provides a slick way to easily automate your browser interactions.

Playwright

Playwright is an end-to-end testing tool from the team at Microsoft. It allows automation of modern web apps across browsers like Chrome, Firefox, and Webkit.

Playwright is actually quite similar to Puppeteer, which we’ll cover next, where some of the same core members who built and maintained Puppeteer actually moved to Microsoft from Google to create Playwright.

Where Puppeteer was a Chromium-based tool only, Playwright steps in and provides support for all modern browsers including Google Chrome and Microsoft Edge by using Chromium, Apple Safari by using WebKit, and Mozilla Firefox.

Using Playwright, we can choose what browser we’d like to run our tests on (or multiple browsers) and issue some straightforward commands for Playwright to follow.

In the above, we’re using Chromium, where we’re able to launch a new browser instance along with a new page, navigate to the Select ingredient, select our option, and check it’s value.

Note, similar to others on this list, you’ll need an additional library like Jest to write assertions.

Tip: if you want to learn more about Playwright, check out our article Playing with Playwright!

Puppeteer

Puppeteer is a similar tool to Playwright brought to you by the Google team. It followed what was an initial release of headless Chrome, where with Puppeteer, you can automate tasks right inside of the Chrome browser using native Chrome features. This helps to prevent flakiness some other frameworks tend to have.

As we dive into the code, you’ll notice that Puppeteer looks really similar to the Playwright example, minus a few small syntax changes. This is due to the history we talked about above, where Playwright was built by the team who used to work on Puppeteer.

In the above, just like Playwright, we launch our browser and navigate to our page, select an option from the dropdown, and make sure it’s what we expect it to be.

While production support is only available for Chrome, other browser support appears to be on its way, starting with Firefox.

Similar to Playwright, we need a library like Jest to handle our assertions.

Selenium WebDriver

Selenium WebDriver is a tool that’s been around for quite a long time, long before the newer Playwright, Puppeteer, and Cypress.

Selenium uses the WebDriver protocol to interface with the browser which uses a server to interact with the browser like ChromeDriver or the geckodriver for Firefox.

In our test, we need to create a new driver where we configure it as a new instance of Chrome. with our driver, we can navigate to our page just like any other tool, where we then use the API to find our elements, interact with our elements, and make sure that it’s working as expected.

We can also see in the above that we pull in assert which we use to write the assertion and verify it’s working as expected.

TestCafe

TestCafe is a framework that touts its ability to run tests out-of-the-box without any need for WebDriver. It also has the capability of running on all modern browsers.

While TestCafe is still based off of JavaScript, its syntax looks a bit different compared to the other ones we’re reviewing.

In the above, we first define a fixture which will be the page that we want to visit in our test. We next define our selectors before we even get to the test, which in this instance, we want to define our dropdown as well as the option that element which will be a child of the dropdown.

With our selections, we click our way through, selecting our element by its label instead of its value, then make sure its working as expected.

We can see that we get the assertion here out of the box without needing another dependency.

Webdriver.io

Webdrverio.io is a tool that can run on both the WebDriver and Chrome DevTools protocol to automate browser testing. As standards have changed, their support of running both gives developers the flexibility of using whichever option works for their use case.

It’s also capable of native mobile testing through an emulator, simulator, or on device, as well as native desktop applications written with tools like Electron.js.

While Webdriver.io primarily runs on WebDriver, you’ll notice the syntax is a bit more similar to some of the newer frameworks we’ve discussed.

Here, we’re loading up a page by URL just like any of our other tests and similar to Cypress, we’re able to do it in one line. Then, we find our Select element using a jQuery-like syntax, where we can both select our value and get the value, to verify it’s correct.

In this example, we’re pulling in Jasmine as our way to add assertions.

End-to-End Visual Testing with Applitools

The good news, is whatever testing tool you choose as your Protractor alternative, Applitools already has you covered.

Applitools supports a wide variety of SDKs that interface directly with your testing tool of choice, making integration super easy.

To find examples of using Applitools with all of the tools above along with many others, check out the Applitools tutorials page.

The post Migrating End-to-End Protractor Tests for Angular Projects appeared first on Automated Visual Testing | Applitools.

Recently I’ve put together a bunch of tutorials: an overview of Applitools, how to test Storybook with Angular, how to quickly troubleshoot bugs in React apps, and how to test Vue apps with Cypress.

If you’ve gone through these, you’ll notice that the visual tests complete in seconds — faster than Nic Cage can jack your ride.

How so fast?

The answer is simple: Applitools Ultrafast Grid. Each time you run a visual test in Applitools, Ultrafast Grid renders that page across a broad range of browsers and configurations. In parallel. In seconds.

Applitools Visual AI then grabs a screenshot of each page, compares it to its baseline screenshot, and determines visual differences and the root cause unpinning them. In less than a minute, your cross-browser testing is done and your developers have what they need to fix any visual bugs.

It’s our very own ludicrous mode (a.k.a. how a Tesla can go from zero to 60 mph in a little over two seconds).

But more than a cool technical trick, Ultrafast Grid can help you keep your app development projects on schedule.

In this article, I will demonstrate the Ultrafast Grid system with test runs and a variety of configuration settings, such as multiple browsers, viewports, and devices, to show Applitools’ efficiency in delivering results.

First off, make sure you have the following installed and configured on your machine:

• Angular
• Storybook
• Applitools

Before we delve into writing code, let’s take a behind-the-scenes look at how Applitools Ultrafast Grid works.

Life before Ultrafast Grid

Before the arrival of the Ultrafast Grid, visual tests were run in this specific order:

• A test run checked the pages one by one.
• A screenshot was taken for each page.
• The screenshot was uploaded to the backend server, where it was analyzed (that is, compared to previous baselines).
• Based on the results, the test would either fail or keep running, checking other pages.

So far, so good!

But problems arise when hundreds of screenshots are uploaded to the backend server to be analyzed. Varying parameters ranging from different viewports, different browsers, and different device emulators can also slow things down.

To help solve this, Applitools designed the Ultrafast Grid system to run tests quickly.

Life with Ultrafast Grid

Applitools Ultrafast Grid is split into two components: server-side and client-side. Here’s a diagram of how it works:

The Ultrafast Grid client is a Node JS library, used internally by both Applitools Storybook and Cypress SDKs. Here’s more on the Ultrafast Grid client.

That code snippet instantiates a new Ultrafast Grid client and returns an object. In this case, we are only interested in the openEyes() method returned.

When called, the openEyes() method starts a new test run and sends the Ultrafast Grid backend server details about it– including, but not limited to the application name, batch or test name, the browsers used, and different variations of browser settings to be adapted while running the tests. This method returns a Promise to an object with the following functions: checkWindow() and close().

This method call instructs the Ultrafast Grid backend server to prepare a testing environment for a new test run that requires running the test over two different browsers. The first browser emulates an iPhone X, while the second specifies the desktop viewport to run the test.

To start collecting snapshots, the test issues a call to checkWindow() function. The Ultrafast Grid client handles this call and collects all the needed resources to store the snapshot locally.

At the end of the test, you issue a call to close() method to close and finish the test run.

At this moment, all the DOM Snapshots collected locally during the test run are sent to the Ultrafast Grid backend server. Based on the test run requirements, sent previously with the openEyes() method, the Ultrafast Grid:

• Launches a number of browsers with different viewports and device emulators.
• Runs all of the DOM snapshots in parallel.
• Collects image screenshots.
• Sends all the screenshots to the Applitools AI server to do all the testing analysis and returns the results.

Finally, it’s worth mentioning that Ultrafast Grid sits behind a family of Applitools SDKs including the following:

• Applitools for Selenium IDE

• Java 3 Selenium SDK
• JS4 Selenium SDK
• C# Selenium SDK
• Python Selenium SDK
• Ruby Selenium SDK
• WebdriverIO SDK
• Cypress
• Storybook

Now that you understand how the Ultrafast Grid system works so efficiently, let’s throw a spanner in the works by running tests with a variety of browser configuration settings. Then, we’ll review the results on the Applitools Test Manager.

Source code

For this article, I’ve chosen to write a few Storybook stories and use Applitools for the custom Angular ContentEditable component. I’ve described and used this in my previous article on Mixing Storybook with Angular with a sprinkle of Applitools.

There have been some changes to the Applitools Eyes SDK for Storybook npm package since my previous article was published. I’d recommend removing the old package and installing the new one by following these steps:

Step 1: Remove the old @applitools/eyes.storybook NPM package by issuing the following command:

npm remove @applitools/eyes.storybook

copy code to clipboard

Step 2: Install the new @applitools/eyes-storybook NPM package by issuing the following command:

npm i @applitools/eyes-storybook

copy code to clipboard

That’s it!

Applitools Ultrafast Grid Demo

Before writing our tests, let’s run the application and make sure it’s working fine.

Step 1: Clone the application repo.

git clone https://github.com/thisdot/storybook-angular-applitools.git

copy code to clipboard

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

Go to the folder /storybook-angular-applitools then run this command:

npm install

copy code to clipboard

Step 3: Run the app by issuing the following command:

ng serve

copy code to clipboard

Now that we are sure the application is up and running switch back to the Terminal and hit Ctrl+c twice. This terminates the running application.

Step 4: Run the Storybook stories by issuing the following command:

npm run storybook

copy code to clipboard

Step 5: Run the Applitools Eyes SDK for Storybook by issuing the following command:

npx eyes-storybook

copy code to clipboard

Make sure you get an Applitool API Key and store it on your machine.

To set the APPLITOOLS_API_KEY environment variable locally on your machine you can use the export command on Mac OS or set command on Windows as follows.

For a complete tutorial on how to install and run Applitools Storybook SDK for Angular, check out this article: Storybook Angular Tutorial.

Back to the command above, this command simply opens the Storybook stories, runs them one by one, and then sends all the DOM snapshots to Applitools Ultrafast Grid, which then renders them.

If you expand the first test run, you get the following results:

Now that the app, Storybook stories, and Applitools are running locally, let’s start playing with our visual tests.

Visual UI tests with custom viewports

Keeping in mind that Applitools with Storybook doesn’t need any kind of configuration, the important test configurations are auto-inferred by Applitools. However, if you want to play around with the test configuration, you have two options to specify:

• Environment variables
• The applitools.config.js file

For this demonstration, I will make use of the applitools.config.js file. For a full list of test configuration, check the Advanced Configuration section on the @applitools/eyes-storybook repo on Github.

When you’re using Applitools with Storybook, there’s no need to add any specific Applitools commands or set test configuration to enable visual testing.

Applitools Eyes SDK runs the Storybook stories, takes a snapshot of each, and sends the DOM snapshots to the Ultrafast Grid backend server. It saves the test run with the default test configuration.

Step 1: Add a new JavaScript file to the root of your application. Give it a name of applitools.config.js.

Step 2: Add the appName and batchName configuration settings as follows:

Step 3: Run the test case on two different browsers with two different viewports by adding the following:

Consequently, Ultrafast Grid launches a set of instances for each of the browsers and runs the tests simultaneously. The first time these tests are run, we create baseline images to compare against during subsequent test runs.

Step 4: Save and run the tests again by issuing the following command:

npx eyes-storybook

copy code to clipboard

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

I’ve switched the Test Manager view to the Batch Summary View.

Notice how Applitools Ultrafast Grid ran your tests twice, as per the test configuration file above. The test configuration above specified two different browsers with two different viewports. This means that the Ultrafast Grid runs every test twice– once per browser configuration set.

Running this test yields an execution time of just four seconds! To be clear, this is what we spent rendering baseline images, once the DOM snapshots were uploaded. Even so, that’s really fast.

It’s the duty of the Ultrafast Grid to analyze the test configuration file attached to the test and spawn, in parallel, a number of browser instances to handle the test run efficiently.

Visual UI tests with device emulation

Let’s run another test. This time, instead of specifying the browser viewports, we will specify a device emulation for the browser. Device emulation uses a Chrome browser, with the viewport dimensions, and user agent string, specific to that device.

Step 1: Replace the content of the applitools.config.js file with the following configuration:

In this test configuration, we are specifying to the Ultrafast Grid to run this test over a Chrome browser with a device emulation of an iPhone X using a landscape screen orientation.

Ultrafast Grid supports only the Chrome browser for running tests over a device emulation, so you can skip the name of the browser. I’m explicitly specifying the browser name to make it very clear that this is a browser emulation and not a real device.

For a complete list of device emulators supported by the Chrome browser, take a look at this page: Chromium Device Emulators.

Step 2: Save and run the tests by issuing the following command:

npx eyes-storybook

copy code to clipboard

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

I’ve switched the Test Manager view to the Batch Summary View.

As per the new test configuration file, the Ultrafast Grid runs your tests on a Chrome browser with a device emulation for iPhone X. Hence, the browser name shown is Safari 11.0 and landscape with a viewport of 812×375.

Notice that running this test yields an execution time of just two seconds! Again, this is once the DOM snapshot has been uploaded. But still…

Finally, in Applitools, baseline snapshots are stored as per test configuration settings. Different test configuration settings generate different baseline snapshots. You can’t compare apples to oranges, right?

That’s why, if you click on the snapshot above (after switching back to Batch steps view) and show both the baseline and the current test run, you won’t get any baseline snapshot–because it’s the first time we’re running the test with these configuration settings.

100 Visual UI tests

Let’s go crazy and run 100 Visual/UI tests with a combination of test configurations.

Step 1: Replace the content of the applitools.config.js file with the following configuration:

In this test configuration, we are running 100 tests with 50 unique view ports on two major browsers: Firefox and Google Chrome.

Step 2: Save and run the tests by issuing the following command:

npx eyes-storybook

copy code to clipboard

During this time, the Eyes Storybook SDK will read all Storybook stories in the application, run them one by one using the Storybook engine, generate a DOM snapshot for each test, and finally upload the results to the Eyes server. At this moment, the Eyes server will run each and every DOM snapshot, render an image snapshot, and store it as a baseline snapshot.

The Eyes SDK/Server took only 21 seconds to complete all the above tasks, create baselines, and report the results on Applitools Test Manager Dashboard, for the entire batch of 100 test runs for a single Storybook story.

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

I’ve switched the Test Manager view to the Batch Summary View.

Let’s see the power of the Eyes server when running a regression testing cycle.

Step 4: Let’s introduce a visual change on the Storybook story and run the Eyes SDK once again.

Replace the content of the /src/stories/index.stories.js file with the following:

view rawregression-testing-cycle hosted with by GitHub

Now the ContentEditableComponent should render with a Blue background.

Step 5: Run the tests again by issuing the following command:

npx eyes-storybook

copy code to clipboard

Once again, the Eyes SDK/Server took only 21 seconds to upload the DOM snapshot, run the entire batch of visual UI tests, and display the results on the Applitools Test Manager Dashboard.

Notice the error message generated saying that “A total of 100 differences were found”.

Because the change we introduced affected the entire batch of test runs, therefore, all the current tests failed in comparison with the baseline snapshots, due to the visual change introduced earlier.

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

The Test Manager highlights the differences between the baseline snapshot and the current test run and displays a mismatch icon near the snapshots.

At this moment, you can either accept the new changes and make them the new baseline or reject them and keep the old baseline.

Once again, it takes the power of the Ultrafast Grid to analyze the test configuration file and set up the testing environment as needed.

See for yourself

Here’s a step-by-step tutorial video of how I did all the steps above. You can see how it took just 20 seconds for the Applitools Storybook SDK to upload all the DOM snapshots, then use Applitools Visual AI to look for visual regressions:

Conclusion

By now, you have some insight into how Applitools Ultrafast Grid functions behind the scenes when running your visual tests.

Want to get run your own tests ludicrously fast? Applitools Ultrafast grid is GA for Storybook, Cypress, and Selenium IDE. If you use Selenium WebDriver with Java, JavaScript, C#, Python, or Ruby, request to join our early access program.

Happy Testing!

Photo by Sander Jeurissen on Unsplash

The post How I ran 100 UI tests in just 20 seconds [Revisited] appeared first on Automated Visual Testing | Applitools.

Cypress and Angular make a great combination. Angular is a useful and broadly-adopted front-end framework, focused on single-page applications. Cypress makes it easy to set up, write, run, and debug tests.

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 Eyes integrates with dozens of testing frameworks, such as Cypress.io, Storybook, and Selenium. Applitools provides SDKs for use in your projects to seamlessly communicate and interact with Applitools Eyes.

Getting Started with Cypress, Angular, and Applitools

With all the attention on Angular visual UI testing, I thought it would be appropriate to share step by step tutorial on this subject. Specifically, Angular UI testing using Applitools and Cypress.io.

First, ensure that these are properly installed on your machine:

• Angular
• Cypress.io
• Applitools

Before we delve into writing code, let’s take a behind-the-scenes look at how Applitools and Cypress.io integrate together.

Applitools / Cypress.io Integration

Applitools integrates with Cypress.io and offers a general-purpose library to embed within your project, whether it be the Angular, Vue or React app.

The Cypress library,  Applitools Eyes Cypress SDK, adds a few commands to the main cy object. 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. Here’s a diagram:

Now that you understand how the Applitools/Cypress.io integration works, let’s start coding a few visual tests for an Angular app using Applitools and Cypress.io.

Source code

For this article, I’ve chosen to write a few E2E Cypress.io tests against the Angular Pizza Creator app written by Todd Motto which is available on Github. The Pizza Creator app builds a pizza ordering form that basically allows the client to customize the pizza ingredients before ordering it. I’ve cloned the Github repo, created a new Angular CLI app and migrated all the source code there. The new Github repo can be found here.

Now, I will take you on a series of steps to install Applitools and Cypress.io on an existing Angular app, add a Cypress.io test and finally verify the results on the Applitools Test Manager.

Steps 1-3: Prepare The Demo App

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

git clone git@github.com:bhaidar/pizza-creator.git

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

yarn install

Step 3: Run the app:

yarn run start

And you should see something like this:

There you go. It works!

Steps 4-7: Install And Configure Cypress

Step 4: Add Cypress package to the project:

yarn add cypress -D

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

Step 5: Replace the content of the e2e script inside the package.json file with:

“e2e”: “cypress open”

Step 6: Open the Cypress Electron app by issuing the following command:

yarn run e2e

This command opens the Cypress Electron app and also creates a cypress.json file and a cypress folder in your app’s root directory. The cypress folder is where we will be writing our tests.

Step 7: Inside the cypress.json file in the root of the application folder, add:

{

“baseUrl”: “http://localhost:4200”

}

Now that Cypress is running properly, let’s add our first E2E test.

Steps 8-9: Install and Run End To End Test

Step 8: Inside the cypress\integration folder, create the pizza.spec.js file and paste:

View the code on Gist.

The single E2E test focuses on testing the function of the pizza ordering form by filling out all the required fields on the form, selecting the pizza size and then finally adding one or more toppings.

The spec file is self-explanatory. There’s just one thing to note here in relation to the selectors used inside cy.get() methods. The best practice is to avoid using IDs and CSS classes to select elements from the DOM. They will make your tests brittle because they’re subject to change. A better approach is to use data-* attributes or actual component names.

I’ve been through the source code and added a few data-cy attributes to the elements referenced inside the e2e test.

Step 9: Run the single E2E test by issuing the following command:

yarn run e2e

Great! Our E2E test successfully passes, verifying that the app functions well and can fill the pizza order form, select the pizza size and add one or more toppings.

E2E tests are sufficient in testing the overall Web app. However, wouldn’t it be beneficial and more effective to complement the E2E tests with visual ones? This adds the value of detecting any visual change or difference upon running E2E regression testing.

Steps 10-11: Add Applitools SDK

Since Applitools integrates seamlessly with Cypress.io, let’s add the Applitools Cypress NPM package to the project.

Step 10: Add the Applitools Eyes Cypress SDK package to the project.

yarn add @applitools/eyes-cypress -D

Step 11: Configure the Applitools Eyes Cypress SDK by issuing the following command:

npx eyes-setup

Now that Applitools Eyes Cypress SDK is configured, we can start using it in our tests.

Let the visual testing begin!

Steps 12-13: Run Test With Applitools To Capture Visual Data

Step 12: Revisit the cypress\integration\pizza.spec.js file and replace its content with:

View the code on Gist.

The code is self-documented.

To integrate Applitools Eyes Cypress SDK into a spec file, you’ll 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 13: Check the test run in Applitools Test Manager:

Clicking on the test name (in this case, Fill form to order pizza) yields a single snapshot that the Eyes SDK has taken during the running of the test.

The snapshot is labeled full page. The image shows the pizza order form is populated, a pizza size is selected and toppings are selected and showing on top of the pizza.

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

Steps 14-16: Demo Applitools With A CSS Change

We will simulate a visual difference by introducing a change on the font-weight for the selected toppings and let Applitools detect this. Now run the test again and see the results.

Step 14: Open the src/app/pizza-app/components/pizza-toppings/pizza-toppings.components.scss file and change the following CSS class to:

input {

border: 0;

clip: rect(0 0 0 0);

height: 1px;

margin: -1px;

overflow: hidden;

padding: 0;

position: absolute;

width: 1px;

}

&–focused {

background: rgba(0, 0, 0, 0.15);

    font-weight: 500;

}

Run the test.

Step 15: Issue the command to run the E2E tests again. The test case fails and Applitools detects a visual change for the selected toppings font weight.

Notice how the Applitools Test Manager recorded the second run of the test case and highlighted the visual difference between the two snapshots?

Step 16: Click on the snapshot and compare it to the baseline.

In case you can’t see both snapshots side by side, locate the View menu and select Show both.

To access the source code of this article, feel free to grab a copy of it here: pizza-creator.

Conclusion

You now have some insight on how Applitools speeds up your visual testing experience when you’re developing apps with Cypress and Angular.

My upcoming articles will explore Applitools further, unveil more features and allow you to carry on with E2E and Visual UI Testing easily.

Happy Testing!

Further Reading

In my previous posts, I have showcased the power of the Applitools Ultrafast Grid system and demonstrated how Applitools integrates fluidly with Cypress.io inside a React JS app.

Here is a recap of some of the previous Applitools topics I’ve touched on:

1. Applitools – The automated visual regression testing framework
2. Mixing Storybook with Angular with a sprinkle of Applitools
3. Troubleshoot and fix React bugs fast
4. Visually test VueJS apps using Cypress.io and Applitools
5. How I ran 100 UI tests in just 20 seconds
6. Visually Test Vue.js application using Applitools and Storybook
7. React UI Testing, step by step, with Applitools and Cypress.io

For more information on Applitools

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

The post Cypress and Angular Testing with Applitools appeared first on Automated Visual Testing | Applitools.

Recently I’ve put together a bunch of tutorials: an overview of Applitools, how to test Storybook with Angular, how to quickly troubleshoot bugs in React apps, and how to test Vue apps with Cypress.

If you’ve gone through these, you’ll notice that the visual tests complete in seconds — faster than Nic Cage can jack your ride.

How so fast?

The answer is simple: Applitools Ultrafast Grid. Each time you run a visual test in Applitools, Ultrafast Grid renders that page across a broad range of browsers and configurations. In parallel. In seconds.

Applitools Visual AI then grabs a screenshot of each page, compares it to its baseline screenshot, and determines visual differences and the root cause unpinning them. In less than a minute, your cross-browser testing is done and your developers have what they need to fix any visual bugs.

It’s our very own ludicrous mode (a.k.a. how a Tesla can go from zero to 60 mph in a little over two seconds).

But more than a cool technical trick, Ultrafast Grid can help you keep your app development projects on schedule.

In this article, I will demonstrate the Ultrafast Grid system with test runs and a variety of configuration settings, such as multiple browsers, viewports, and devices, to show Applitools’ efficiency in delivering results.

First off, make sure you have the following installed and configured on your machine:

• Angular
• Storybook
• Applitools

Before we delve into writing code, let’s take a behind-the-scenes look at how Applitools Ultrafast Grid works.

Life before Ultrafast Grid

Before the arrival of the Ultrafast Grid, visual tests were run in this specific order:

• A test run checked the pages one by one.
• A screenshot was taken for each page.
• The screenshot was uploaded to the backend server, where it was analyzed (that is, compared to previous baselines).
• Based on the results, the test would either fail or keep running, checking other pages.

So far, so good!

But problems arise when hundreds of screenshots are uploaded to the backend server to be analyzed. Varying parameters ranging from different viewports, different browsers, and different device emulators can also slow things down.

To help solve this, Applitools designed the Ultrafast Grid system to run tests quickly.

Life with Ultrafast Grid

Applitools Ultrafast Grid is split into two components: server-side and client-side. Here’s a diagram of how it works:

The Ultrafast Grid client is a Node JS library, used internally by both Applitools Storybook and Cypress SDKs. Here’s more on the Ultrafast Grid client.

View the code on Gist.

That code snippet instantiates a new Ultrafast Grid client and returns an object. In this case, we are only interested in the openEyes() method returned.

When called, the openEyes() method starts a new test run and sends the Ultrafast Grid backend server details about it– including, but not limited to the application name, batch or test name, the browsers used, and different variations of browser settings to be adapted while running the tests. This method returns a Promise to an object with the following functions: checkWindow() and close().

View the code on Gist.

This method call instructs the Ultrafast Grid backend server to prepare a testing environment for a new test run that requires running the test over two different browsers. The first browser emulates an iPhone X, while the second specifies the desktop viewport to run the test.

To start collecting snapshots, the test issues a call to checkWindow() function. The Ultrafast Grid client handles this call and collects all the needed resources to store the snapshot locally.

At the end of the test, you issue a call to close() method to close and finish the test run.

At this moment, all the DOM Snapshots collected locally during the test run are sent to the Ultrafast Grid backend server. Based on the test run requirements, sent previously with the openEyes() method, the Ultrafast Grid:

• Launches a number of browsers with different viewports and device emulators.
• Runs all of the DOM snapshots in parallel.
• Collects image screenshots.
• Sends all the screenshots to the Applitools AI server to do all the testing analysis and returns the results.

Finally, it’s worth mentioning that Ultrafast Grid sits behind a family of Applitools SDKs including the following:

• Applitools for Selenium IDE

• Java 3 Selenium SDK
• JS4 Selenium SDK
• C# Selenium SDK
• Python Selenium SDK
• Ruby Selenium SDK
• WebdriverIO SDK
• Cypress
• Storybook

Now that you understand how the Ultrafast Grid system works so efficiently, let’s throw a spanner in the works by running tests with a variety of browser configuration settings. Then, we’ll review the results on the Applitools Test Manager.

Source code

For this article, I’ve chosen to write a few Storybook stories and use Applitools for the custom Angular ContentEditable component. I’ve described and used this in my previous article on Mixing Storybook with Angular with a sprinkle of Applitools.

There have been some changes to the Applitools Eyes SDK for Storybook npm package since my previous article was published. I’d recommend removing the old package and installing the new one by following these steps:

Step 1: Remove the old @applitools/eyes.storybook NPM package by issuing the following command:

npm remove @applitools/eyes.storybook

Step 2: Install the new @applitools/eyes-storybook NPM package by issuing the following command:

npm i @applitools/eyes-storybook

That’s it!

Applitools Ultrafast Grid Demo

Before writing our tests, let’s run the application and make sure it’s working fine.

Step 1: Clone the application repo.

git clone https://github.com/thisdot/storybook-angular-applitools.git

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

Go to the folder /storybook-angular-applitools then run this command:

npm install

Step 3: Run the app by issuing the following command:

ng serve

Now that we are sure the application is up and running switch back to the Terminal and hit Ctrl+c twice. This terminates the running application.

Step 4: Run the Storybook stories by issuing the following command:

npm run storybook

Step 5: Run the Applitools Eyes SDK for Storybook by issuing the following command:

npx eyes-storybook

Make sure you get an Applitool API Key and store it on your machine.

To set the APPLITOOLS_API_KEY environment variable locally on your machine you can use the export command on Mac OS or set command on Windows as follows.

View the code on Gist.

For a complete tutorial on how to install and run Applitools Storybook SDK for Angular, check out this article: Storybook Angular Tutorial.

Back to the command above, this command simply opens the Storybook stories, runs them one by one, and then sends all the DOM snapshots to Applitools Ultrafast Grid, which then renders them.

If you expand the first test run, you get the following results:

Now that the app, Storybook stories, and Applitools are running locally, let’s start playing with our visual tests.

Visual UI tests with custom viewports

Keeping in mind that Applitools with Storybook doesn’t need any kind of configuration, the important test configurations are auto-inferred by Applitools. However, if you want to play around with the test configuration, you have two options to specify:

• Environment variables
• The applitools.config.js file

For this demonstration, I will make use of the applitools.config.js file. For a full list of test configuration, check the Advanced Configuration section on the @applitools/eyes-storybook repo on Github.

When you’re using Applitools with Storybook, there’s no need to add any specific Applitools commands or set test configuration to enable visual testing.

Applitools Eyes SDK runs the Storybook stories, takes a snapshot of each, and sends the DOM snapshots to the Ultrafast Grid backend server. It saves the test run with the default test configuration.

Step 1: Add a new JavaScript file to the root of your application. Give it a name of applitools.config.js.

Step 2: Add the appName and batchName configuration settings as follows:

View the code on Gist.

Step 3: Run the test case on two different browsers with two different viewports by adding the following:

View the code on Gist.

Consequently, Ultrafast Grid launches a set of instances for each of the browsers and runs the tests simultaneously. The first time these tests are run, we create baseline images to compare against during subsequent test runs.

Step 4: Save and run the tests again by issuing the following command:

npx eyes-storybook

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

I’ve switched the Test Manager view to the Batch Summary View.

Notice how Applitools Ultrafast Grid ran your tests twice, as per the test configuration file above. The test configuration above specified two different browsers with two different viewports. This means that the Ultrafast Grid runs every test twice– once per browser configuration set.

Running this test yields an execution time of just four seconds! To be clear, this is what we spent rendering baseline images, once the DOM snapshots were uploaded. Even so, that’s really fast.

It’s the duty of the Ultrafast Grid to analyze the test configuration file attached to the test and spawn, in parallel, a number of browser instances to handle the test run efficiently.

Visual UI tests with device emulation

Let’s run another test. This time, instead of specifying the browser viewports, we will specify a device emulation for the browser. Device emulation uses a Chrome browser, with the viewport dimensions, and user agent string, specific to that device.

Step 1: Replace the content of the applitools.config.js file with the following configuration:

View the code on Gist.

In this test configuration, we are specifying to the Ultrafast Grid to run this test over a Chrome browser with a device emulation of an iPhone X using a landscape screen orientation.

Ultrafast Grid supports only the Chrome browser for running tests over a device emulation, so you can skip the name of the browser. I’m explicitly specifying the browser name to make it very clear that this is a browser emulation and not a real device.

For a complete list of device emulators supported by the Chrome browser, take a look at this page: Chromium Device Emulators.

Step 2: Save and run the tests by issuing the following command:

npx eyes-storybook

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

I’ve switched the Test Manager view to the Batch Summary View.

As per the new test configuration file, the Ultrafast Grid runs your tests on a Chrome browser with a device emulation for iPhone X. Hence, the browser name shown is Safari 11.0 and landscape with a viewport of 812×375.

Notice that running this test yields an execution time of just two seconds! Again, this is once the DOM snapshot has been uploaded. But still…

Finally, in Applitools, baseline snapshots are stored as per test configuration settings. Different test configuration settings generate different baseline snapshots. You can’t compare apples to oranges, right?

That’s why, if you click on the snapshot above (after switching back to Batch steps view) and show both the baseline and the current test run, you won’t get any baseline snapshot–because it’s the first time we’re running the test with these configuration settings.

100 Visual UI tests

Let’s go crazy and run 100 Visual/UI tests with a combination of test configurations.

Step 1: Replace the content of the applitools.config.js file with the following configuration:

View the code on Gist.

In this test configuration, we are running 100 tests with 50 unique view ports on two major browsers: Firefox and Google Chrome.

Step 2: Save and run the tests by issuing the following command:

npx eyes-storybook

During this time, the Eyes Storybook SDK will read all Storybook stories in the application, run them one by one using the Storybook engine, generate a DOM snapshot for each test, and finally upload the results to the Eyes server. At this moment, the Eyes server will run each and every DOM snapshot, render an image snapshot, and store it as a baseline snapshot.

The Eyes SDK/Server took only 21 seconds to complete all the above tasks, create baselines, and report the results on Applitools Test Manager Dashboard, for the entire batch of 100 test runs for a single Storybook story.

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

I’ve switched the Test Manager view to the Batch Summary View.

Let’s see the power of the Eyes server when running a regression testing cycle.

Step 4: Let’s introduce a visual change on the Storybook story and run the Eyes SDK once again.

Replace the content of the /src/stories/index.stories.js file with the following:

View the code on Gist.

Now the ContentEditableComponent should render with a Blue background.

Step 5: Run the tests again by issuing the following command:

npx eyes-storybook

Once again, the Eyes SDK/Server took only 21 seconds to upload the DOM snapshot, run the entire batch of visual UI tests, and display the results on the Applitools Test Manager Dashboard.

Notice the error message generated saying that “A total of 100 differences were found”.

Because the change we introduced affected the entire batch of test runs, therefore, all the current tests failed in comparison with the baseline snapshots, due to the visual change introduced earlier.

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

The Test Manager highlights the differences between the baseline snapshot and the current test run and displays a mismatch icon near the snapshots.

At this moment, you can either accept the new changes and make them the new baseline or reject them and keep the old baseline.

Once again, it takes the power of the Ultrafast Grid to analyze the test configuration file and set up the testing environment as needed.

See for yourself

Here’s a step-by-step tutorial video of how I did all the steps above. You can see how it took just 20 seconds for the Applitools Storybook SDK to upload all the DOM snapshots, then use Applitools Visual AI to look for visual regressions:

Conclusion

By now, you have some insight into how Applitools Ultrafast Grid functions behind the scenes when running your visual tests.

Want to get run your own tests ludicrously fast? Applitools Ultrafast grid is GA for Storybook, Cypress, and Selenium IDE. If you use Selenium WebDriver with Java, JavaScript, C#, Python, or Ruby, request to join our early access program.

Happy Testing!

The post How I ran 100 UI tests in just 20 seconds appeared first on Automated Visual Testing | Applitools.

To better understand the Applitools Storybook SDK for Angular, here is a tutorial on how to build a small AngularJS application from scratch, adding some Storybook stories, and then finally performing visual regression testing using the Applitools SDK to generate snapshots for us to view and analyze.

You can find the source code for this article on GitHub by following this link storybook-angular-applitools repo.

Create Angular 7 App using the latest CLI

Make sure you have the latest Angular CLI installed. In my case, I will be using the Angular CLI v7.0.2. Create a new Angular App using the following npm command:

View the code on Gist.

Create the ContentEditable Component

The ContentEditable component we are going to build in this section wraps an HTML <div> element and adds an HTML attribute of contenteditable=”true”. The component implements the ControlValueAccessor so that the component can be used like any other Angular form control inside HTML forms.

View the code on Gist.

The HTML fragment above renders in the browser as an editable area that users can click and enter any text or HTML.

Create a new component file and add the following markup to contenteditable.component.html file:

View the code on Gist.

Next, add the code below to the contenteditable.component.ts file:

View the code on Gist.

The component is straightforward and follows the best practices in building a ControlValueAccessor. It defines a single @Input() property to allow the consumer of this component to control its styling.

If you want to fully understand how ControlValueAccessor works in Angular check out Max’s article titled Never again be confused when implementing ControlValueAccessor in Angular.

Next, add the following HTML snippet to the app.component.html file:

View the code on Gist.

Define the styles() method inside the AppComponent class:

View the code on Gist.

And now run the application. You should see something similar to this below.

You can start typing in the yellow editable rectangle and you will see whatever you type underneath.

Let’s switch gears and add Storybook to the application.

Add Storybook packages

We need to add Storybook for Angular to your application. The Storybook website offers a detailed installation guide on Storybook for Angular. Once installed, apply the following changes, so that Storybook runs correctly with your Angular 7 application.

Open the src/app/tsconfig.app.json file and make sure the exclude property has the following values:

View the code on Gist.

Open the .storybook/tsconfig.json file and paste the following:

View the code on Gist.

Create and run a few Storybook stories

Add the following Storybook stories into the file located at src/app/stories/index.stories.ts:

View the code on Gist.

The first story renders the ContentEditable component with a yellow background. While the second renders the component with a red background.

Run the Storybook tool to view and test your stories by issuing the following CLI command:

View the code on Gist.

You should be able to see something similar to this:

Now that we are sure the Storybook stories are up and running, let’s set up Applitools to use these stories and run our visual automated tests.

Add and run Applitools Storybook SDK for Angular

To add Applitools Storybook SDK for Angular to this application issue the following CLI command:

View the code on Gist.

Make sure to grab an Applitools API Key and store it on your machine. For a complete tutorial on how to install and run Applitools Storybook SDK for Angular, you may check this link: Storybook Angular Tutorial.

To run the Storybook stories and send the snapshots to the Applitools Server, issue the following command:

View the code on Gist.

The command simply opens the Storybook stories, runs them one by one, and then sends all the DOM snapshots to the Applitools Server.

Let’s have a look at the test results inside Applitools Test Manager.

Review test results on Applitools Test Manager

We can see the results of the tests we just ran from the Applitools Test Manager. To access the Applitools Test Manager, navigate to https://www.applitools.com. Sign in to get onto the Dashboard.

For a detailed look at the Applitools Test Manager, you can check this article: Applitools – The automated visual regression testing framework.

The results for running the Storybook tests show the following:

The test manager lists the test runs or batches (as referred to by Applitools) on the left- hand side. Clicking on any of the batches displays all of the snapshots for all of the Storybook stories in your application.

Click on the first snapshot (the red color) to expand and review it in detail:

A rich toolbox is available to zoom in/out on the snapshot and compare this snapshot to any previously taken, known as the baseline. In this case, since this is the first time we are running the stories, there won’t be any baseline set. Therefore, Applitools Test Manager sets these snapshots as a baseline for upcoming regression test cycles.

Next, we’re going to simulate what happens when we have a visual regression in one of our components. To do this most easily, we’ll change one of our Storybook stories to render our component in a way that will be different from the baseline images we took earlier. Then, when we re-run the visual testing, we should see a discrepancy appear that we’ll have to resolve.

To do this, let’s assume that the story named in the red background above, has the ngModel value changed and now reads as follows:

View the code on Gist.

Now run this command:

View the code on Gist.

The command gives you a detailed test result every time you run it. Check the following results:

View the code on Gist.

Running the second story fails, as expected because we changed the content that was initially displayed inside the ContentEditable component. The test result output provides you with a link to check the discrepancies online. Click on the link to open the issues directly in the Applitools Test Manager:

A new batch is displayed on the left-hand side with a status of Unresolved. The Unresolved status indicates that the Applitools Test Manager discovered a discrepancy between the two test runs. This will require your input in order to resolve the discrepancy. Either approve the difference, and create a new baseline, or reject it to keep the original baseline.

Notice the blue square above indicating the Not Equal sign. This means the second snapshot test run has some differences to the first test run snapshot (the baseline). Clicking on the first snapshot reveals the differences between both snapshots. The current one and the baseline. The differences in content are highlighted in blue. You can also compare the new snapshot with the baseline by selecting both:

This should display both side by side and all differences are highlighted for you. You may spend more time at the Applitools Test Manager to explore all the rich features provided for you to do a thorough analysis on running the story tests.

Conclusion

This article touched the surface on how you can mix together Storybook and Angular together in one application. By means of Applitools Storybook SDK for Angular, you can provide automated visual UI testing by running the Storybook stories and generate snapshots that are then sent to the Applitools AI Server to compare and analyze and prepare the test results for you.

You can grab the code for this article by cloning the repository on Github.

So how are you going to test the Storybook components in your Angular apps?

This post was written by Bilal Haidar, a mentor with ThisDot

The post How to visually test Storybook components in Angular applications [step-by-step tutorial] appeared first on Automated Visual Testing | Applitools.

On September 9, 1947, Grace Hopper recorded the first computer bug ever in the Harvard Mark II computer’s logbook. The bug in question? Believe it or not, an actual bug – a moth – flew into the relay contacts in the computer and got stuck. Hopper duly taped the moth into the logbook. Then she added the explanation: “First actual case of bug being found.” (This might be the most famous moth in history.)

If only things were this simple today. As software continuously grows in complexity, so does the process of testing and debugging. Nowadays, the lifecycle of a bug in software can be lengthy, costly, and frustrating.

Finding and fixing bugs early on in the application development stage is cheaper and easier than doing so during QA, or worse, in production. This is because, as any developer knows, debugging is often a case of finding a needle in a haystack. The smaller the haystack (the code you’re looking through) the easier it is to find the needle (or bug). That haystack is going to be smaller when you’re looking at the code written by one developer, as opposed to several developers or more.

This dynamic is what’s driving the trend of ‘Shift-Left’ to do more testing – not just unit, but functional and visual – during the development phase of the app lifecycle. Recognizing the importance of this trend, we want to help frontend developers and have developed new visual testing capabilities as part of Applitools Eyes.

Expanding Left to Developers

When you adopt Shift Left, it impacts your software development lifecycle. Developers now need to do more testing as they code, to discover bugs as soon as they create them.

Shift-Left testing paired with an increasing velocity of releasing software to meet business demand, all while maintaining high quality, presents huge challenges for R&D teams. If you’re a developer, you have to do more. Write more code, do more testing, manage the merge, etc. All to deliver more features in less time and with better quality. Because of these challenges, we are seeing new tools being adopted by developers such as the Cypress test framework and Storybook UI component development framework, and more.

So we expanded our AI powered visual testing platform to integrate with Cypress and Storybook. Now you have the tools to do visual UI testing as you code — at the speeds you need for Agile development, continuous integration, and continuous delivery (CI-CD).

Ultrafast Cross-browser Visual Testing with Cypress

The Applitools Cypress SDK lets you instantly run visual UI tests on top of your functional tests by running browsers in parallel, in the cloud, to generate screenshots for multiple browsers and viewports. Our visual AI engine then compares these screenshots to find significant differences and instantly detect visual bugs.

If you’re making the move to Cypress, we made this process run ultra-fast so that you won’t experience any slowdown when adding Applitools Visual AI Testing into your work stream. We do this by using containers to test all options simultaneously, in parallel. We call this feature our Applitools Ultrafast Grid. It takes the DOM snapshot and renders the various screens on different browsers and various viewport sizes corresponding to multiple mobile devices, desktops, etc.  

For the first time, you can use Cypress to effectively test to see if you have any cross-browser bugs. And, you can now do responsive testing to see if any visual bugs occur on different screen sizes.

This increased speed lets you cover more tests cases, increase test coverage, and catch more bugs before they hit production.

Check out Applitools’ new Cypress SDK and sign up for a free Applitools Eyes account at (https://applitools.com/cypress)

Instantly Detect UI Component Bugs with Visual Testing

The Applitools Storybook SDK visually tests UI web components, without any test code and works with React, Angular or Vue.

The way it works is that we scan the Storybook library to inventory all components. Then we upload a DOM Snapshot for each component’s visual state to our Applitools Ultrafast Grid.

Once these DOM Snapshots are on our ultrafast grid, we run visual validations in parallel. Validations of all visualization states of all components, on all specified viewport sizes, on both Chrome and Firefox, happen at once.

All this lets you perform ultra-fast codeless validation of your Storybook component libraries in seconds. You can think of this as visual testing at the speed of unit testing. You can learn more in this blog post on visually testing React components in Storybook and this webinar on our Cypress and Storybook SDKs.

Check out Applitools’ new Storybook SDK and sign up for a free Applitools Eyes account at (https://applitools.com/storybook).

The Final Word: Expanding Left, Not Shifting Left!

I want to emphasize that, even though we’ve talked a lot about developers and Cypress in this post, we still remain as committed as ever to QA teams, and the frameworks they use, including Selenium.

Selenium remains an incredibly important part of the test automation world, and we continue to remain a sponsor of both the Selenium project itself and SeleniumConf.  In the coming weeks and months, you’ll see us release new functionality that backs this point up.

While we are delivering new visual testing tools to developers, we remain committed to serving test automation engineers and QA analysts. That’s why we are talking about expand left, rather than using the more common term shift-left.

If you have any questions or want to try the application visual testing approach, please reach out or sign up for a free Applitools account today!

How will you start visual UI testing with Cypress or Storybook? 

The post How to Implement Shift Left for your Visual Testing appeared first on Automated Visual Testing | Applitools.

Listen to Gil Tayar’s webinar on the new Applitools SDKs for Cypress and Storybook, which enable developers to test the visual appearance of their apps across all responsive web platforms, including React, Vue, and Angular.  

Developers want their tests to run fast. In an increasingly agile world, waiting ten minutes or more for test results is a huge no-no. A new generation of browser automation tools recognize that need-for-speed and enable frontend developers to quickly automate their browser tests.

But those tests also need to check the application’s visual elements. Does the login page look okay? Does it look good in Firefox? What about mobile browsers, in 768px width? And does it still look good in 455px with a device pixel ratio of 2? These are just a few of the questions developers ask when building responsive web applications.

To check the visual quality of your application, across all browsers and in all those responsive widths, would necessitate a humongous grid of browsers, and an unreasonable amount of time. Far more than the two to five minutes usually available for a developer’s tests.

Applitools’ new SDKs for Cypress and Storybook enable you to do just that: write a set of visual regression tests that run through your pages and components, and have the pages and components render in Applitools Ultrafast Grid, in parallel, on a large set of browsers and widths, and return the result in less than a minute.

One minute. That’s quicker than most functional test suites, and approaching the time required for unit testing.

Listen to Applitools Architect Gil Tayar, as he discusses the new generation of visual UI testing tools. Tools that move the burden of the visual work to cloud, and enable you to check what was till now impossible to check locally: the visual appearance of your application across multiple responsive platforms.

Source code, slides, and video

You can find companion code for Gil’s talk on this GitHub repo.

We also have detailed, step-by-step tutorials on how to use Applitools with Cypress, Storybook + React, Storybook + Vue, and Storybook + Angular.

Here’s Gil’s slide deck:

And here’s the full webinar recording:

Check out these resources, and if you have any questions, please contact us or set up a demo.

How are you going to start visually testing with Cypress or Storybook?

The post Visual UI Testing at the Speed of Unit Testing, with new SDKs for Cypress and Storybook appeared first on Automated Visual Testing | Applitools.

Great turnout at our last Selenium Meetup, which celebrated its 1 year anniversary yesterday!

We had 2 awesome sessions:

(1) Alon Heller from Alcatel-Lucent explained how Protractor makes life easier when it comes to testing AngularJS applications. 

(2) Adam Carmi from Applitools talked about visual test automation using Selenium.

Here’s a recap & slide-deck links, for anyone who missed our event: 

Protractor is an end-to-end test framework, built on top of Selenium, for AngularJS applications. In the 1st session, Alon Heller from Alcatel-Lucent explained how Protractor makes life easier when it comes to testing AngularJS applications. He showed how to configure, write, debug and run tests using Protractor, and discussed best practices and tips to get the most out of the framework. You can see Alon’s slide-deck here.

In the 2nd session, Adam Carmi from Applitools talked about visual test automation using Selenium. His presentation covered visual testing in-depth, including: what visual testing is and why it should be automated; challenges involved with visual test automation, and modern tools that addresses those challenges. Adam also reviewed available open-source and commercial Selenium-based visual testing tools, and showed how visual test automation fits in the development / deployment lifecycle. You can find Adam’s slide-deck below:

To read more about Applitools’ visual UI testing and Application Visual Management (AVM) solutions, check out the resources section on the Applitools website. To get started with Applitools, request a demo or sign up for a free Applitools account.

The post How Protractor makes it easier to visually test Angular apps appeared first on Automated Visual Testing | Applitools.

So, is Protractor easier than Selenium?

Yes!

In this blog post, I’ll give you a taste of why you’d benefit from using Protractor for your JavaScript tests instead of using Selenium webdriver directly, even if your app has nothing to do with AngularJS yet – or just a partial usage. 

If you peek inside Protractor you’ll see the good old Selenium Web Driver (aka WebDriverJS aka selenium-webdriver).

Protractor is essentially a wrapper for the JavaScript Selenium webdriver. Therefore – you get all the capabilities of the webdriver – along with a number of very useful additions.

Oh – so they probably added some Angular stuff – right?

Yes!

They added accessors to angular models, bindings, ng-options – and finding elements inside ng-repeat. These additions make querying for elements much easier. For example – let’s get all the ages of the cats that the repeater adds:

<div ng-repeat="cat in pets">
    <span>{{cat.name}}</span>
    <span>{{cat.age}}</span>
</div>

// test code:
// ---------
// Returns a promise that resolves to an array of
// WebElements from a column
var ages = element.all(
    by.repeater('cat in pets').column('{{cat.age}}'));

Ever struggled with the challenge of determining when the page is truly ready, i.e. all the asynchronously fetched resources are ready and processed? Check out waitForAngular that does exactly that.

But I don’t use Angular yet – should I keep reading?

Yes!

They added other goodies – accessors (locators) by button text, partial button text – and the very cool option to find by a combination of CSS and text (get me all the divs with class ‘pet’ and text ‘dog’).

Also – they added the addLocator function to help you add your own locators – so that, for a fictional example, you can get elements by their handlebars properties.

But I’m already using Selenium extensively

First of all, pat yourself on the back – you’re already in better shape than most teams out there. You can install Protractor and use it with your existing infrastructure. Simply configure Protractor to operate against your Selenium servers.

Please note: You’ll have to take some additional steps to run Protractor successfully on non-Angular pages. We will cover this issue in the next post.

OK – please continue

Ye… oh – great, let’s see now:

One more addition that makes life easier for users is globals.

Protractor adds these objects to the global namespace: browser, element and by. Now go ahead and spot the difference between the two canonical examples:

Protractor (9 lines of code, not including the comments):

// starting right here with two Jasmine lines.
// All the rest is preconfigured separately and very easily.
describe('angularjs homepage', function() {
    it('should add one and two', function() {
        // Just go ahead and use the webdriver – the configuration
        // took care of the initialization
        browser.get('http://juliemr.github.io/protractor-demo/');
        // much shorter than driver.findElement… webdriver.By…
        element(by.model('first')).sendKeys(1);
        element(by.id('gobutton')).click();
        // please appreciate how naturally
        // expect works with this flow
        expect(element(by.binding('latest')).getText()).
             toEqual('3');
    });
});

Selenium (17, longer, lines of code, not including the comments):

// Defining some requirements – to be able to use assertions
// and test syntax
var assert = require('assert'),
    test = require('selenium-webdriver/testing'),
    webdriver = require('selenium-webdriver');

// Now we can write a test
test.describe('Google Search', function() {
    test.it('should work', function() {
        // We need to setup the webdriver…
        var driver = new webdriver.Builder().
            withCapabilities(webdriver.Capabilities.chrome()).
            build();

        // finally we can actually do something
        driver.get('http://www.google.com');
        // all the functions are accessed via driver of webdriver.
        // Much typing!
        driver.findElement(webdriver.By.name('q'))
            .sendKeys('webdriver');
        driver.findElement(webdriver.By.name('btnG')).click();
        // spoon-feeding the assertion using then
        // and resolving the value
        driver.getTitle().then(function(title) {
            assert.equal(title, 'webdriver - Google Search');
        });
    
        // calling this ourselves
        driver.quit();
    });
});

More! I want moar!!!

Sure, why not?

Starting to work with Protractor is a breeze. You get the Jasmine test library out of the box – with a bonus patch to the ‘expect’ function to easily provide validation through assertion. You get webdriver-manager to take care of the local webdriver server for you and make it easy to test against a remote server. You don’t have to run your tests directly as scripts using node – as your initial attempts with Selenium will have you do.

This brings us to another point – Protractor has much better documentation, in my opinion. For example, here is the tutorial for Protractor. Not bad, right?

In Conclusion…

Protractor is neat – and I see it as a very useful evolution from Selenium Webdriver for JavaScript.

It’s not limited to testing only AngularJS apps – even though these two are usually mentioned together. However – it was designed mainly for Angular and some work is required, at least currently, to use it on non-angular pages. We will review this in the next post. If you plan to gradually move your site/app to Angular – you can start writing your Protractor E2E tests right now – and I will show you how.

If you’re already using Angular, there’s a bunch of guides out there that will help you get started with Protractor – and I intend to provide more information in future posts.

To read more about Applitools’ visual UI testing and Application Visual Management (AVM) solutions, check out the resources section on the Applitools website. To get started with Applitools, request a demo or sign up for a free Applitools account.

The post Protractor vs. Selenium: Which is easier for testing? appeared first on Automated Visual Testing | Applitools.