Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 22 additions & 9 deletions docs/visual-testing/workflows/test-execution.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,16 +9,15 @@

# Test Execution Workflow

This workflow is responsible for generating snapshots (screenshots) of the website or app under test.
Users new to visual testing often have an existing test suite in WebdriverIO, Cypress or a similar framework.
With Sauce Visual testing existing test suites can be enhanced with a few extra "take a snapshot" statements and that is all it takes to implement this workflow. Test Execution can be executed for both E2E and Component Testing.
The Test Execution Workflow is the process responsible for generating snapshots (screenshots) of your website or application during automated tests. This is a core component of visual testing and allows teams to catch unintended UI changes before they reach production.

Check warning on line 12 in docs/visual-testing/workflows/test-execution.md

View workflow job for this annotation

GitHub Actions / vale

[vale] docs/visual-testing/workflows/test-execution.md#L12

[sauce.UnclearAntecedent] Instead of 'This is', try starting this sentence with a specific subject and verb.
Raw output
{"message": "[sauce.UnclearAntecedent] Instead of 'This is', try starting this sentence with a specific subject and verb.", "location": {"path": "docs/visual-testing/workflows/test-execution.md", "range": {"start": {"line": 12, "column": 150}}}, "severity": "WARNING"}
If you're already using an existing test suite with WebdriverIO, Cypress, or another supported testing framework, integrating Sauce Visual is simple. You only need to add a few take a snapshot statements to your current tests—no need to rewrite your test logic. This workflow supports both End-to-End (E2E) and Component Testing out of the box.

Check warning on line 13 in docs/visual-testing/workflows/test-execution.md

View workflow job for this annotation

GitHub Actions / vale

[vale] docs/visual-testing/workflows/test-execution.md#L13

[sauce.Simplicity] Remove 'simple'. Be precise instead of subjective.
Raw output
{"message": "[sauce.Simplicity] Remove 'simple'. Be precise instead of subjective.", "location": {"path": "docs/visual-testing/workflows/test-execution.md", "range": {"start": {"line": 13, "column": 143}}}, "severity": "WARNING"}

## Integrations

Sauce Visual provides integrations with different kinds of frameworks:
Sauce Visual seamlessly integrates with various testing frameworks to support different testing strategies:

- **E2E Testing** allows you to navigate a website and capture snapshots any time this is needed.
- **Component Testing** allows you to test extensively all your components.
- **E2E Testing** - Navigate through your website as a user would and capture snapshots at key steps to validate the UI visually.
- **Component Testing** - Thoroughly test UI components in isolation to ensure they render consistently under all expected states.

<div className="box-wrapper" markdown="1">
<div className="box box1 card">
Expand All @@ -39,13 +38,27 @@

## First Test Execution

Upon executing your tests for the first time, a visual baseline is automatically created in our system. This baseline serves as the standard for all subsequent tests and matches based on the metadata as described in the [Baseline Matching](../../visual-testing.md#baseline-matching).
When your visual tests are run for the first time, Sauce Visual automatically creates a visual baseline. This baseline acts as the reference point for all future visual comparisons. The baseline is generated based on snapshot metadata as detailed in the [Baseline Matching](../../visual-testing.md#baseline-matching).

After the initial test run:

* The baseline is available on the [Sauce Visual Builds](https://app.saucelabs.com/visual/builds) page.
* A user must review and approve the baseline. For more information see [Reviewing and Accepting baselines](./review.md#reviewing-and-accepting-baselines)
* Once approved, the baseline is locked and used as the standard for future test runs.

:::note
The baseline is created during the first execution and must be manually approved to become the definitive visual standard.
:::

The newly created baseline needs to be reviewed and approved by a user. This can be done in the [Sauce Visual Builds](https://app.saucelabs.com/visual/builds) page. Once approved, see [Reviewing and Accepting baselines](./review.md#reviewing-and-accepting-baselines), the baseline is "locked" and will be used for all subsequent tests.

## Subsequent Test Executions

As new tests are run, they are compared to the original baseline, with any deviations highlighted to signal visual changes. These comparisons are integral for detecting any unintended visual modifications early in your development cycle. All test builds, including the initial baseline and subsequent runs, can be monitored and managed through the Sauce Labs platform at [Sauce Visual Builds](https://app.saucelabs.com/visual/builds).
Every time you rerun your tests:
* New snapshots are automatically compared against the locked baseline.
* Any visual differences are flagged and highlighted in the Sauce Visual interface.
* These comparisons help identify unintended UI regressions early in the development lifecycle.

All visual builds—including the initial baseline and all subsequent test runs—can be tracked, reviewed, and managed via the [Sauce Visual Builds](https://app.saucelabs.com/visual/builds) dashboard.

[Follow me to learn more](./review.md)

Expand Down