Forem: Dmitry Sheiko

Optimizing End-to-End Testing with Playwright: Best Practices for Speed & Reliability

Dmitry Sheiko — Wed, 26 Mar 2025 11:23:24 +0000

End-to-end tests are crucial but can become slow and flaky if not optimized. This article explores practical strategies to enhance Playwright tests, covering parallelization, network stubbing, test isolation, and debugging techniques. Whether you're a developer or QA engineer, these insights will help you improve test efficiency and reliability.

Playwright #Testing #QA #DevOps #WebDev

Puppetry 3 : test automation without coding

Dmitry Sheiko — Wed, 27 Nov 2019 11:52:35 +0000

Nowadays nobody would argue the importance of automated testing. Yet end-to-end tests are often hard to write and even harder to maintain. There are many solutions to help with it. Puppetry is a test constructor, which allows you building test suites without any coding. QA-engineer can record user scenario in a built-in browser, extend the generated test case with browser commands and assertions, manage the suite structure (like drag’n’drop) and run tests. Puppetry translates Gherkins-styled test specification into a Jest/Puppeteer project, executes it and shows the report. This project can be simply plugged in CI/CD pipeline.

You may think of it as an advanced UI over Puppeteer with more than 60 visualized methods and assertions. These are designed to make the test development as easy as possible. For example, with Puppetry you say “I assert that target FOO is currently located above BAR”. It results in the code computing styles of both targets and comparing them.

It may sound as play-toy, but in reality we can implement with Puppetry quite sophisticated test strategies. For example we can address dynamic content, run performance budgeting, test CSS regression, Chrome extensions, web-components, transactional emails and Google Analytics tracking.

Real-world test cases can be hard to debug. Modern web applications are highly dynamic, meaning the pages are changing in response to user actions. So we have to remember when addressing an element that it can be not yet rendered or already destroyed in that particular point in time. Luckily Puppetry let use set breakpoints as well as run test in interactive mode. In both cases the test run pause when reaching the problem point, so you can observe the actual page state and call DevTools to check the DOM tree.

Yeah, Puppetry is where the test automation makes fun. Not persuaded? Just check the video out.

Download links https://github.com/dsheiko/puppetry/releases
Official site https://puppetry.app/

How to create automated functional tests in no time

Dmitry Sheiko — Fri, 26 Jul 2019 09:24:56 +0000

A brief tutorial showing how to record a simple test suite.

Puppetry is an open-source desktop application that gives non-developers the ability to create, manage, and integrate automated tests for Web
puppetry.app/

Credits:
Pacific Sun by Nicolai Heidlas available under Attribution Creative Commons 4.0 license Royalty Free Music from HookSounds (hooksounds.com)

How to create a kick-ass image preview with LQIP

Dmitry Sheiko — Thu, 11 Jul 2019 13:40:09 +0000

Images in HTML, what could be easier? However when you have many of them on a page, they do not appear immediately. That depends on caching strategy and bandwidth, but still if you don’t take a special care it may look quite ugly. Basically we need to fill in the slots with something appropriate while images are loading. In other words we need placeholders. Probably the most prominent technique here is LQIP (low quality image placeholder). It was adopted by Google, Facebook, Pinterest, Medium and others. The idea is to load page initially with low quality images and once the page is fully loaded replace them with full quality ones. As placeholder one can use embedded transparent SVG, spinner animated image, solid color, blurred and minified original image. But even more, with modern tools we can do something really fancy. For example, we can use images shape or silhouette as a placeholder. Moreover, we can generate Data-URLs with desired effect during the build and address from IMG tag.

The basics

Let’s get there step by step. First we come back to the basics. HTML IMG tag didn’t change much for last 30 years:

    <img alt="Lorem ipsum" src="./img/test.jpg" />

Yet , we have now srcset attribute to tackle responsive web design:

    <img srcset="./img/test-1x.jpg 1x,
                 ./img/test-2x.jpg 2x"
         src="./img/test.jpg" alt="Lorem ipsum" />

Here we enlist image sources per display density (1x, 2x). Thus browser will load double sized version (test-2x.jpg) on Retina devices. Or we can be more specific:

    <img srcset="./img/test-320w.jpg 320w,
                 ./img/test-480w.jpg 480w,
                 ./img/test-800w.jpg 800w"
         src="./img/test.jpg" alt="Lorem ipsum" />

Now we specify image source width (320w, 480w, 800w) and browser will use that information to pick the most suited source. Note that we still use src attribute to specify fallback source, which will be used by legacy browsers.

Now, to the point. What can we do to beautify image loading? The simplest thing is to add an animated spinner as background for image slots. So while image are loading we see the animation. As the loading completed, we see the images covering the background.

But what if some images fail to load? Diverse browsers render “broken” images differently, but equally awful. To fix it you can target some of them with CSS. However, most universal way, I assume, is to use JavaScript:

    Array.from( document.querySelectorAll( "img:not(.is-processed)" ) ).forEach( img => {
        img.classList.add( "is-processed" );
        img.addEventListener( "error", () => {      
          img.style.opacity = 0;
        }, false );
      });

Lazysizes

Alternatively we can go with a loader library Lazysizes to achieve better perceived performance. It unlocks new options. For example, we can achieve empty image placeholder like that:

    <img    
      src="./img/test-fallback.jpg"
      srcset="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw=="
        data-srcset="./img/test-320w.jpg 320w,
            ./img/test-480w.jpg 480w,
            ./img/test-800w.jpg 800w"
        data-sizes="auto"
        class="lazyload" />

Thus the browser will show the embedded placeholder (transparent or low quality image) until it loads an image corresponding to the viewport from data-srcset.

Lazysizes adds lazyloaded CSS class to image element on load event and that we can use, for an instance, to implement blur-up placeholder:

    <style>
        .blur-up {
            -webkit-filter: blur(5px);
            filter: blur(5px);
            transition: filter 400ms, -webkit-filter 400ms;
        }

        .blur-up.lazyloaded {
            -webkit-filter: blur(0);
            filter: blur(0);
        }
    </style>
    <img src="./img/test-lqip.jpg" data-src="./img/test.jpg" class="lazyload blur-up" />

So the low quality image (test-lqip.jpg) will be blurred until the original image (test.jpg) loaded.

In the article How to use SVG as a Placeholder, and Other Image Loading Techniques you can find insights of LQIP techniques with drawing effect, based on shapes and silhouettes. Why not put it in practice? So we have to generate a low-quality image, precisely, a Data-URL with SVGO and specify it in src or srcset attribute of IMG tag, while full-quality image sources we set in data-srcset, pretty much as we examined above. The most convenient way to achieve it would be with Webpack. The tool transforms imported images during the build. So we can refer the result (e.g. generated SVGO) straight in the application code. Let’s see in practice.

First, we install dependencies:

    npm i -S lazysizes react react-dom

As you see we are going to use Lazysizes library and React.js.

Now it’s the turn to install developer dependencies. We start with babel packages:

    npm i -D @babel/cli @babel/core @babel/node @babel/preset-env @babel/preset-react babel-loader

Then go Webpack ones:

    npm i -D webpack webpack-cli clean-webpack-plugin   file-loader image-webpack-loader

The file-loader plugin makes Webpack resolving imports of images and image-webpack-loader optimizes imported

As we have dependencies, we can create base webpack configuration for React.js/Babel application. We put in src/img test-1x.jpg and double-sized test-2x.jpg demo images and to src/index.jsx the entry script:

    import React from "react";
    import { render } from "react-dom";
    import Image from "./component/Image";
    import "lazysizes";    
    import productImg1x from "./img/test-1x.jpg";
    import productImg2x from "./img/test-2x.jpg";

    render(
      <Image
          placeholder={ productImg1x }
          srcSet={[ productImg1x, productImg2x ]}
          alt="A farm"
          ></Image>,
      document.getElementById( "app" )
    );

Here we load lazysizes library, importing out both images and passing them to Image component. The HTML file may look like that

    <div id="app"></div>
    <script src="build/index.js"></script>

Silhouette

Silhouette placeholder we can generate with image-trace-loader . The plugin extracts image outlines and returns them as SVGO.

We have to extend our Webpack configuration with the following:

module: {
  rules: [
    {
      test: /\.(gif|png|jpe?g)$/i,
      use: [
        {
          loader: "image-trace-loader"
        },
        {
          loader: "file-loader",
          options: {
            name: "src-[name].[ext]"
          }
        },
        {
          loader: "image-webpack-loader",
          options: {
            bypassOnDebug: true, // webpack@1.x
            disable: true // webpack@2.x and newer
          }
        }
      ]
    }
  }
]

Now in the code we can receive imported images as:

    import { src, trace } from './image.png';

Where trace is generated SVGO Data-URL and src the full-quality image. It gives us the following Image component:

src/component/Image.jsx

    import React from "react";

    export default function Image({ placeholder, alt, srcSet }) {
        return <img
          className="lazyload"
          alt={ alt }
          src={ placeholder.trace }
          data-srcset={ srcSet.map( ( img, inx ) => `${ img.src } ${ inx + 1}x` ).join( ", " ) }
          data-sizes="auto"
          />;
    }

Now we run Webpack and get the following loading frames:

Shape

Sqip-loader split a given picture in arbitrary number of primitive shapes as as triangles, rectangles, ellipses, circles, polygons and others.

For shape-based placeholder in Webpack configuration the loader rule may look like:

{
  loader: "sqip-loader",
  options: {
    numberOfPrimitives: 20,
    mode: 1,
    blur: 0
  }
}

Here we require 20 triangle-based shapes and no blur. That makes image imports available in the code as follows:

    import { src, preview } from './image.png';

Where preview is generated SVGO Data-URL and src the full-quality image. So we have to modify src/component/Image.jsx. Instead of { placeholder.trace } we go with { placeholder.preview }.

Well, let’s run Webpack and check the page in the browser:

Blur up

This technique is often refereed as SQIP. While image load we see a blurred low quality placeholders similar to how it works on Medium. The placeholders can be also generated by Sqip-loader. However this time we are going to set blur:

{
  loader: "sqip-loader",
  options: {
    numberOfPrimitives: 20,
    mode: 1,
    blur: 30
  }
}

The result looks so:

Recap

We we brushed up on src and srcset image attributes. We learnt how to use them together with their data-counterparts and Lazysizes library to take advantage of LQIP technique. We set up Webpack and a simple React.js example to fiddle with three SQIP approaches: silhouette, shapes and blurup.

The full code source of the example can be found here:

https://github.com/dsheiko/boilerplate/blob/master/webpack-sqip/

Testing signup flow with activation by email

Dmitry Sheiko — Tue, 09 Jul 2019 10:21:00 +0000

Functional testing isn’t something new. We all do it, less or more, with different tools and approaches. However when it comes to flows, where transactional emails (signup confirmations, password resets, purchase notifications and others) involved that may still bring questions. For example, we instruct the testing tool to navigate to the registration page, fill out the form and press the submit button. The web-application sends email with activation link. So we need the testing tool to read the email message, parse it and navigate the link. The first challenge is to connect the testing tool with the mail server. It’s not a big deal if your mail server exposes a REST API. Otherwise you need to consider a specialized service such as Sendgrid, Mailgun, Email Yak, Postmark.

Mail Server API

To say truth, it can be also achieved with Restmail.net. It's free, it's requires no registration, it allows to create dynamically inboxes, it exposes a REST API to read received emails. However all the sent messages are public. The REST API is dead simple:

    GET /mail/<user>
    DELETE /mail/<user>

So you can send an email to, let’s say, joe1@restmail.net and receive its contents with GET /mail/joe1. Naturally you can delete it afterwards with DELETE /mail/joe1

Polling Inbox

Well, but how we can use it in test cases? We need a function, which polls mail server API for inbox updates. The function shall find the email messages sent during the testing session, parse the action link and return it for testing methods. I suggest the following implementation:

     function pollForValue({ url, interval, timeout, parserFn, parserPayload = {}, requestFn = null }) {
        const request = requestFn ? requestFn : async ( url ) => {
          const rsp = await fetch( url );
          if ( rsp.status < 200 || rsp.status >= 300  ) {
            return {};
          }
          return await rsp.json();
        };

        return new Promise(( resolve, reject ) => {
          const startTime = Date.now();
          pollForValue.attempts = 0;

          async function attempt() {
            if ( Date.now() - startTime > timeout ) {
              return reject( new Error( `Polling: Exceeded timeout of ${ timeout }ms` ) );
            }
            const value = parserFn( await request( url ), parserPayload );
            pollForValue.attempts ++;
            if ( !value ) {
              return setTimeout( attempt, interval );
            }
            resolve( value );
          }
          attempt();

        });
     }

As you call the function it polls a given URL until message(s) received or timeout. It returns the parsed value (e.g. activation link) and accepts an options object with the following properties:

url – REST API resource. Here http://restmail.net/mail/
interval – interval between polling requests in ms
timeout – maximal allowed time span for the function to loop in ms
parserFn – callback that receives the REST API response and parses it for the desired value. The pollForValue function will poll the provided URL until parserFn returns a truthy value (or timeout)
requestFn – (OPTIONAL) a callback to replace default window.fetch
parserPayload - (OPTIONAL) extra payload for parserFn callback

Test Application

So we have mail server API and polling function. Next, we going to try it in diverse testing tools. For that we will need a real world example. Imagine, we are testing ACME forum application built with NodeBB. Our goal is to fill out the registration form (http://localhost:4567/register) and submit it:

It brings us to the next page where we have tick on the GDPR checkboxes.

As the form submitted the application sends confirmation email. Here we go with pollForValue function. We call it to poll the REST API until the email message arrived. The function will use the following parsing logic to get the activation link from NodeBB default email template:

    function parseActivationLink( text ) {
        const re = /(http\:[^\"]+4567\/con[^\"]+)/g,
              res = text.match( re );
        return res ? res[ 0 ].replace( "=\r\n", "" ) : null;
    }

Thus we obtain the activation URL, which we follow to complete the registration.

Testing with Selenium WebDriver

Selenium WebDriver is probably the most popular testing tool. Not the most effortless, I would say, but still, it’s definetelly one you’ve heard about. So we setup the dev environment for Node.js and write our test case. Untill the point where we make ACME forum to send activation email everything is certain:

    const { Builder, By, Key, until } = require( "selenium-webdriver" );

    (async function main() {
      const driver = await new Builder().forBrowser("chrome").build(),
            USER = "ctest1";
      try {
        await driver.get( "http://localhost:4567/register" );

        await driver.findElement( By.id("email" ) )
          .sendKeys( `${ USER }@restmail.net`, Key.RETURN );
        await driver.findElement( By.id("username" ) )
          .sendKeys( USER , Key.RETURN );
        await driver.findElement( By.id("password" ) )
          .sendKeys( `Password1234`, Key.RETURN );
        await driver.findElement( By.id("password-confirm" ) )
          .sendKeys( `Password1234`, Key.RETURN );

        await driver.findElement( By.id("gdpr_agree_email" ) )
          .click();

        await driver.findElement( By.id("gdpr_agree_data" ) )
          .click();

        await driver.findElement( By.css("#content form button" ) )
          .click();

        //…  

      } catch ( e ) {
        console.log( e );
      } finally {
        await driver.quit();
      }
    })();

We populate the first form with test values, where email shall be in restmail.net domain. As we are done with the last field, the form gets automatically submitted. Then we tick on the checkboxes and click on submit button. Now let’s do the polling. So we put at the beginning of the script a module to simplify HTTP(S) requests:

    const fetch = require( "node-fetch" );

Next we place our pollForValue and parseActivationLink functions. Now we can extend test steps with:

       const activationLink = await pollForValue({ url: `http://restmail.net/mail/${ USER }`, 
          interval: 1000, 
          timeout: 600000,  
          parserFn: ( messages ) => {
              if ( !messages ) {
                return null;
              }
               const sentAt = new Date( Date.now() - 1000 ),
                     unseen = messages.find( msg => new Date( msg.receivedAt ) > new Date( sentAt ) );                
              return parseActivationLink( messages[0].html );
          }
        });

        console.log( "Activation link:", activationLink );

        await driver.get( activationLink );

Thus after submitting the second form we make the script polling for newly sent email message. When it received we parse the message body for the activation link. Bingo! We get the link and we make the driver navigating to it.

Testing with Cypress

Recently is gaining momentum a tool called Cypress. I do like it personally for the test debugging. Without polling for mail messages the test script may look like that:

    const USER = "ctest1";
    describe("User registration flow", () => {
        it( "registers user", ( done ) => {
          cy.visit( "http://localhost:4567/register" );

          cy.get( "#email" ).type( `${ USER }@restmail.net` );
          cy.get( "#username" ).type( USER );
          cy.get( "#password" ).type( "Password1234" );
          cy.get( "#password-confirm" ).type( "Password1234" );
          cy.get( "#register" ).click();
          cy.wait( 1000 );
          cy.get("#gdpr_agree_email").click();
          cy.get("#gdpr_agree_data").click();
          cy.get("#content form button.btn-primary").click();

          //...
          done();

        })
      })

Similar to what we did with Selenium we extend the script with pollForValue and parseActivationLink functions. However this time instead of using node-fetch we rather go with built-in cy.request function. That’s where pollForValue’s requestFn option jumps in action:

          pollForValue({ url: `http://restmail.net/mail/${ USER }`, 
                interval: 1000, 
                timeout: 600000,  
                parserFn: ( messages ) => {
                    if ( !messages ) {
                        return null;
                      }
                       const sentAt = new Date( Date.now() - 1000 ),
                             unseen = messages.find( msg => new Date( msg.receivedAt ) > new Date( sentAt ) );                
                      return parseActivationLink( messages[0].html );
                },
                requestFn: ( url ) => {
                    return new Promise(( resolve ) => {
                        cy.request( url )
                            .then( (response) => {
                                resolve( response.body );
                            } );
                    });
                }
          }).then(( link ) => { 
            activationLink = link;
            console.log( "Activation link:", activationLink );
            done(); 
          });

So it’s just left to declare activationLink

    let activationLink;

and visit the activation link

    it( "follows the activation link", () => {
       cy.visit( activationLink );
    })

Testing with Puppetry

We’ve just examined how we can do the trick with script-based testing tools. Let’s take now a code-less one – Puppetry. With this tool we don’t script, but use GUI to fulfill our test specifications. Alternatively we record user behavior. Anyways we end up with a test suite, which contains a table of the target elements:

And the test case:

In this example I used template variables. First I defined a new variable TEST_USER_ALIAS that resolves with every test run in ctest1, ctest2 and so on. Then I referred to the variable when typing into email field. Besides I applied template expression {{ faker( "internet.userName", "en" ) }} to generate real-world-like user name. And I also addressed and few environment-dependent variables. Other then that I don’t think you may have difficulties to read the test steps.

Now we extend the test for mail server polling. So we add the command corresponding to the earlier described function pollForValue:

We give in options the retrieving and parsing function similar to one we used with Selenium and Cypress. That will resolve into new template variable ACTIVATION_LINK, which we use to visit the page:

There it is. We’ve got the results:

Recap

Testing user flows that involve transactional emails in a nutshell is not that complex as it’s may be seen. You just need an API to access the mail server and polling method (for example the function from this article). You can achieve with different testing tools, likely with one you’re currently working with.