Advanced Configuration
General Configuration
Configuring the Server URL
By default, Eyes-Playwright communicates with the Applitools public Eyes cloud server, located at https://eyesapi.applitools.com
.
If you have a dedicated cloud or an on-premise server, you can configure a different Eyes server URL using the following code:
eyes.setServerUrl("asd");
Configuring a Proxy
If your company's network requires requests to go through a corporate proxy, you can configure it using the following code:
eyes.setProxy(new ProxySettings("uri"));
eyes.setProxy(new ProxySettings(
"uri",
1234, // port
"username",
"password"
));
Integrating with Functional Tests
You can integrate an Eyes test with a functional test that you have created in a different system.
Every call to eyes.open
and eyes.close
defines a test in Applitools Eyes, and all the calls to eyes.check
between them are called "steps". In order to get a test structure in Applitools that corresponds to the test structure in your functional test, you should open/close tests in every test
call.
For example, when running with JUnit as a test runner:
@BeforeEach
public void beforeEach() {
eyes.open(page, "applitools.com website", "My first Playwright Java test!");
}
@AfterEach
public void afterEach() {
eyes.close();
}
@Test
public void test() {
// ...
}
Organizing Tests in Batches
To manage how visual tests are grouped into batches, you can use the following methods:
Method 1: Environment Variable
Run all the processes that execute Playwright with the same value for APPLITOOLS_BATCH_ID
. For example, run tests with Maven with the same randomly generated UUID:
#! Unix based machines:
APPLITOOLS_BATCH_ID=`uuidgen` mvn test
You can control the batch name displayed in the Test Manager, for example:
export APPLITOOLS_BATCH_ID=`uuidgen`
export APPLITOOLS_BATCH_NAME="Login tests"
mvn test
Method 2: Set Batch
Provide all Eyes instances with the same value for batch ID. For example:
BatchInfo batchInfo = new BatchInfo("name");
batchInfo.setId("id");
eyes.setBatch(batchInfo);
By setting the batch ID using these methods, you can effectively organize and group your visual tests into logical batches.
Test Properties
You can provide additional information about each test in custom fields, which can then show up in Test Manager in their own column.
This is done by calling setProperties
on the configuration, and providing it with an array of properties with the structure {name, value}
. For example:
Configuration configuration = eyes.getConfiguration();
configuration.addProperty("my custom property", "some value");
eyes.setConfiguration(configuration);
Test Results
The results of the test can be consumed as the return value from eyes.close
. Here's an example for creating a formatted output string out of the TestResults
object:
public String formatTestResults(TestResults testResults) {
return "\n" +
"Test name: " + testResults.getName() + "\n" +
"Test status: " + testResults.getStatus() + "\n" +
"URL to results: " + testResults.getUrl() + "\n" +
"Total number of steps: " + testResults.getSteps() + "\n" +
"Number of matching steps: " + testResults.getMatches() + "\n" +
"Number of visual diffs: " + testResults.getMismatches() + "\n" +
"Number of missing steps: " + testResults.getMissing() + "\n" +
"Display size: " + testResults.getHostDisplaySize().toString() + "\n" +
"Steps: " + Arrays.stream(testResults.getStepsInfo()).map(
stepInfo -> "" + stepInfo.getName() + " - " + getStepStatus(stepInfo)
).collect(Collectors.toList());
}
public String getStepStatus(StepInfo stepInfo) {
if (stepInfo.getIsDifferent()) {
return "Diff";
} else if (!stepInfo.getHasBaselineImage()) {
return "New";
} else if (!stepInfo.getHasCurrentImage()) {
return "Missing";
} else {
return "Passed";
}
}
Side by side images
You can download an image of the baseline and checkpoint highlighting differences using the following syntax:
result.stepsInfo[0].apiUrls.sideBySideImage
Stitch Mode
In Applitools Eyes, when taking a full-page screenshot, the SDK captures multiple screenshots of the viewport at different positions on the page and then combines them into a single image. This process is known as "stitching." The stitch mode determines how images are pasted together:
- Scroll stitch mode - This mode simulates scrolling behavior by capturing the viewport screenshot and then scrolling the page to capture additional screenshots at calculated positions. The screenshots are stitched together to create a complete image of the entire page. However, one limitation of this mode is that if the page responds to scroll events and changes its visual appearance, it might result in inconsistencies between the stitched screenshots.
- CSS stitch mode - In this mode, the page is moved by manipulating the CSS property
transform
on the HTML element. The SDK changes thetranslate(x, y)
values to capture different portions of the page. This method is not affected by scroll events, making it more reliable in scenarios where the page dynamically adjusts its layout during scrolling. The default stitch mode isScroll
. To change it:
eyes.setStitchMode(StitchMode.CSS);
eyes.setStitchMode(StitchMode.SCROLL);
Stitch Overlap
The stitch overlap refers to the length of the intersecting area between two screenshots that are stitched together to create a full-page screenshot. It represents the amount of overlapping pixels between adjacent images. The stitch overlap is particularly useful when dealing with fixed elements, such as a footer, that appear in each sub-screenshot. By setting a stitch overlap larger than the size of the footer, you can ensure that the footer is excluded from each individual screenshot and only appears once at the bottom of the full-page screenshot.
The default stitch overlap is 50 pixels. To change it:
eyes.setStitchOverlap(60);
Match Level
The match level determines how Eyes compares the checkpoint image with the baseline image.
The following match levels are available:
-
Strict - (Default) Detects changes in text, font, color, graphics, and position of elements. It aims to detect differences that are visible to the human eye while ignoring differences in pixel values that are platform dependent due to the rendering software and hardware.
-
Layout - Identifies changes in various page elements, such as text, images, buttons, and columns, and verifies that the relative positions of these elements are consistent. This match level can detect elements that have appeared, disappeared, or moved. With this match level, Eyes ignores differences in the actual content text and graphics, color, and other style changes. This level is useful for pages with dynamic content, language localization, and cross-environment testing where a single baseline is used for multiple execution environments.
-
Ignore colors - Similar to the strict match level but ignores changes in colors. It is effective when your content is static but the color varies, for example if there are buttons or screen elements that can appear in a variety of colors.
-
Exact - Pixel-to-pixel comparison of the checkpoint and baseline images. It is sensitive to differences such as rendering anomalies that are not visible to the human eye. It is not recommended for ordinary verification purposes.
-
Dynamic - Recognizes defined text patterns such as a date, email address, or URL. For details, see Dynamic text match level
For more information, see How to use Eyes match levels.
The default match level is Strict
.
eyes.setMatchLevel(MatchLevel.LAYOUT);
eyes.check(Target.window().layout());
eyes.check(Target.window().strict());
eyes.check(Target.window().ignoreColors());
eyes.check(Target.window().exact());
eyes.check(Target.window().dynamic());
Ignore Displacements
Use ignore displacements to hide differences that arise from content whose position on the page has changed. For example, if text is longer in the checkpoint or the size of an image has changed, if IgnoreDisplacements
is set to true
, unchanged content that has shifted position because of the changed text or image will not be marked as a difference.
The default is false
.
For more information, see Hide displacement diffs tool. To change the match level for the rest of the execution:
eyes.setIgnoreDisplacements(true);
To change the match level for a single checkpoint:
eyes.check(Target.window().ignoreDisplacements());
Running with a try-with-resources Statement
We recommend that you use a testing framework when running an Eyes test. Although it is possible to run a test using Java's main()
method, this method does not automatically close all resources; a resource is an object that must be closed after the program is finished with it. When resources are still being used, and are not closed, it causes the main
method to get stuck in an endless loop waiting for the resources to be closed.
To prevent this problem, we recommend that you use the try-with-resources statement
. This statement is a try
statement that declares one or more resources, but ensures that each resource is closed at the end of the statement. This prevents Eyes from getting stuck in an endless loop.
try(ClassicRunner runner = new ClassicRunner()) {
Eyes eyes = new Eyes(runner);
eyes.open(driver, "try-with-resources", "try-with-resources");
eyes.check(Target.window().fully(true));
eyes.close(false);
TestResultsSummary results = runner.getAllTestResults(false);
System.out.println(results);
}