@wdio/ocr-service@1.0.3

Patch Changes

💅 Polish

Update deps

Committers: 1

• Wim Selles (@wswebcreation)

@wdio/visual-service@5.1.0

🚀 New Features

Adding storybook interaction testing

Storybook Interaction Testing

Storybook Interaction Testing allows you to interact with your component by creating custom scripts with WDIO commands to set a component into a certain state. For example, see the code snippet below:

import { browser, expect } from "@wdio/globals";
describe("Storybook Interaction", () => {
  it("should create screenshots for the logged in state when it logs out", async () => {
    const componentId = "example-page--logged-in";
    await browser.waitForStorybookComponentToBeLoaded({ id: componentId });
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-in-state`
    );
    await $("button=Log out").click();
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-out-state`
    );
  });
  it("should create screenshots for the logged out state when it logs in", async () => {
    const componentId = "example-page--logged-out";
    await browser.waitForStorybookComponentToBeLoaded({ id: componentId });
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-out-state`
    );
    await $("button=Log in").click();
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-in-state`
    );
  });
});

Two tests on two different components are executed. Each test first sets a state and then takes a screenshot. You will also notice that a new custom command has been introduced, which can be found here.
The above spec file can be saved in a folder and added to the command line with the following command:

npm run test.local.desktop.storybook.localhost -- --spec='tests/specs/storybook-interaction/*.ts'

The Storybook runner will first automatically scan your Storybook instance and then add your tests to the stories that need to be compared. If you don't want the components that you use for interaction testing to be comparedtwice, you can add a filter to remove the "default" stories from the scan by providing the --skipStories filter. This would look like this:

npm run test.local.desktop.storybook.localhost -- --skipStories="/example-page.*/gm" --spec='tests/specs/storybook-interaction/*.ts'

New Custom Command

A new custom command called browser.waitForStorybookComponentToBeLoaded({ id: 'componentId' }) will be added to the browser/driver-object that will automatically load the component and wait for it to be done, so youdon't need to use the browser.url('url.com') method. It can be used like this

import { browser, expect } from "@wdio/globals";
describe("Storybook Interaction", () => {
  it("should create screenshots for the logged in state when it logs out", async () => {
    const componentId = "example-page--logged-in";
    await browser.waitForStorybookComponentToBeLoaded({ id: componentId });
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-in-state`
    );
    await $("button=Log out").click();
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-out-state`
    );
  });
  it("should create screenshots for the logged out state when it logs in", async () => {
    const componentId = "example-page--logged-out";
    await browser.waitForStorybookComponentToBeLoaded({ id: componentId });
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-out-state`
    );
    await $("button=Log in").click();
    await expect($("header")).toMatchElementSnapshot(
      `${componentId}-logged-in-state`
    );
  });
});

The options are:

clipSelector

• Type: string
• Mandatory: No
• Default: #storybook-root > :first-child for Storybook V7 and #root > :first-child:not(script):not(style) for Storybook V6
• Example:

await browser.waitForStorybookComponentToBeLoaded({
  clipSelector: "#your-selector",
  id: "componentId",
});

This is the selector that will be used:

• to select the element to take the screenshot of
• for the element to wait to be visible before a screenshot is taken

id

• Type: string
• Mandatory: yes
• Example:

await browser.waitForStorybookComponentToBeLoaded({ '#your-selector', id: 'componentId' })

Use the id of the story that can be found in the URL of the story. For example, the id in this URL http://localhost:6006/?path=/story/example-page--logged-out is example-page--logged-out

timeout

• Type: number
• Mandatory: No
• Default: 1100 milliseconds
• Example:

await browser.waitForStorybookComponentToBeLoaded({
  id: "componentId",
  timeout: 20000,
});

The max timeout we want to wait for a component to be visible after loading on the page

url

• Type: string
• Mandatory: No
• Default: http://127.0.0.1:6006
• Example:

await browser.waitForStorybookComponentToBeLoaded({
  id: "componentId",
  url: "https://your.url",
});

The URL where your Storybook instance is hosted.

Committers: 1

• Wim Selles (@wswebcreation)

webdriver-image-comparison@6.0.1

💅 Polish

• 169b7c5: fix(webdriver-image-comparison): export WicElement

Committers: 1

• Christian Bromann (@christian-bromann)

@wdio/visual-service@5.0.1

💅 Polish

• 169b7c5: fix(webdriver-image-comparison): export WicElement
• Updated dependencies [169b7c5]
  • webdriver-image-comparison@6.0.1

Committers: 1

• Christian Bromann (@christian-bromann)

webdriver-image-comparison@6.0.0

💥 Breaking

• 66b9f11:

This PR replaces Canvas as a dependency with Jimp. This removes the need to use system dependencies and will reduce the number of system dependency errors/issues (node-gyp/canvas and so on). This will, in the end, make the life of our end users way easier due to:

• less errors
• less complex test environments

Note

Extensive research has been done and we have chosen to "fork" ResembleJS, adjust it by making use of Jimp instead of Canvas and break the browser API because the fork will only be used in a nodejs environment
Investigation showed that creating a wrapper would even make it slower, so we went for the breaking change in the API by just replacing Canvas with Jimp

Important

There is a performance impact where Canvas is around 70% faster than Jimp. This has been measured without using WebdriverIO and only comparing images. When the "old" implementation with WebdriverIO combined with Canvas or Jimp is compared, we hardly see a performance impact.

🚀 New Features

Update the baseline images through the command line by adding the argument --update-visual-baseline. This will

• automatically copy the actual take screenshot and put it in the baseline folder
• if there are differences it will let the test pass because the baseline has been updated

Usage:

npm run test.local.desktop  --update-visual-baseline

When running logs info/debug mode you will see the following logs added

[0-0] ..............
[0-0] #####################################################################################
[0-0]  INFO:
[0-0]  Updated the actual image to
[0-0]  /Users/wswebcreation/Git/wdio/visual-testing/localBaseline/chromel/demo-chrome-1366x768.png
[0-0] #####################################################################################
[0-0] ..........

💅 Polish

• remove Vitest fix
• add app images
• update the build

Committers: 1

• Wim Selles (@wswebcreation)

@wdio/visual-service@5.0.0

💥 Breaking

• 66b9f11:

This PR replaces Canvas as a dependency with Jimp. This removes the need to use system dependencies and will reduce the number of system dependency errors/issues (node-gyp/canvas and so on). This will, in the end, make the life of our end users way easier due to:

• less errors
• less complex test environments

Note

Extensive research has been done and we have chosen to "fork" ResembleJS, adjust it by making use of Jimp instead of Canvas and break the browser API because the fork will only be used in a nodejs environment
Investigation showed that creating a wrapper would even make it slower, so we went for the breaking change in the API by just replacing Canvas with Jimp

Important

There is a performance impact where Canvas is around 70% faster than Jimp. This has been measured without using WebdriverIO and only comparing images. When the "old" implementation with WebdriverIO combined with Canvas or Jimp is compared, we hardly see a performance impact.

🚀 New Features

Update the baseline images through the command line by adding the argument --update-visual-baseline. This will

• automatically copy the actual take screenshot and put it in the baseline folder
• if there are differences it will let the test pass because the baseline has been updated

Usage:

npm run test.local.desktop  --update-visual-baseline

When running logs info/debug mode you will see the following logs added

[0-0] ..............
[0-0] #####################################################################################
[0-0]  INFO:
[0-0]  Updated the actual image to
[0-0]  /Users/wswebcreation/Git/wdio/visual-testing/localBaseline/chromel/demo-chrome-1366x768.png
[0-0] #####################################################################################
[0-0] ..........

💅 Polish

• remove Vitest fix
• add app images
• update the build

Committers: 1

• Wim Selles (@wswebcreation)

@wdio/ocr-service@1.0.2

Patch Changes

• 6e1e478: Fix contrast and languages

Committers: 1

• Wim Selles (@wswebcreation)

@wdio/visual-service@4.1.3

Patch Changes

🐛 Bug Fixes

• Fixes #286
• Fixes #333

Committers: 1

• Wim Selles (@wswebcreation)

@wdio/ocr-service@1.0.1

Patch Changes

• 083ad82: Fixed OCR cli

Committers: 1

• Wim Selles (@wswebcreation)

@wdio/ocr-service@1.0.0

Major Changes

• a924dfc: # 🚀 New Feature

  Sometimes it can be hard to find an element in a mobile native app or desktop site, with an interactable Canvas, with the default WebdriverIO selectors. In that case, it would be nice if you would be able to use something like OCR (Optical Character Recognition) to interact with elements on your device/screen.

  The new @wdio/ocr-service service provides you with the option to interact with elements based on visible text. It will provide multiple commands to:

  • wait
  • search
  • and interact

  with an element, all based on text.

  The following commands will be added

  • ocrGetText
  • ocrGetElementPositionByText
  • ocrWaitForTextDisplayed
  • ocrClickOnText
  • ocrSetValue

  A CLI command will also be provided to pre-check text received from the image, this can be run by using the command npx ocr-service. For a demo check this video

  ocr-service-cli.mp4

Committers: 1

• Wim Selles (@wswebcreation)