Releases: webdriverio/visual-testing
@wdio/visual-service@9.1.6
Patch Changes
-
0a19d78: Fix
clearRuntimeFolderclearing the actual and diff folders after each spec/feature execution instead of once before all workers start. This caused only the last spec's visual data to be present in the output when running multiple specs.Committers: 1
- Wim Selles (@wswebcreation)
-
ed0bea6: Fix
EISDIRerror when usingresolveSnapshotPathwith the visual service. The service now usesdirname()of the resolved path as the baseline folder, preventing it from creating a directory at a path thatexpect-webdriverio's snapshot service expects to be a file. Fixes #984.Committers: 1
- Wim Selles (@wswebcreation)
-
cbf1d22: Fix incomplete
wdio-ics:optionstype augmentation onWebdriverIO.Capabilities. The global type declaration now uses theWdioIcsOptionsinterface directly, ensuring all supported properties (logName,name) are available to TypeScript users in both standalone and multiremote configurations. Fixes #732.Committers: 1
- Wim Selles (@wswebcreation)
-
Updated dependencies [0a19d78]
-
Updated dependencies [ce74703]
- @wdio/image-comparison-core@1.1.4
@wdio/visual-service@9.1.5
Patch Changes
-
6ed0469: ## Fix: support
appium:optionsnested capability format andavdfallback (#1118)Appium caps need to be prefixed with
appium:, but this can feel redundant when you have a lot of caps. So you can also put them inside theappium:options-object. This was not supported by the visual module and was reported in #1118. It is now supported.The following capabilities are now correctly read from both
appium:-prefixed top-level format and the nestedappium:optionsformat:deviceNamenativeWebScreenshotavd(new, see below)
Second issue that is fixed is that for Android the
deviceNamecould be left away and theavdcould be provided. This is now also supported wheredeviceNametakes priority overavdif both are provided.Committers: 1
- Wim Selles (@wswebcreation)
@wdio/image-comparison-core@1.1.4
Patch Changes
-
0a19d78: Fix
clearRuntimeFolderclearing the actual and diff folders after each spec/feature execution instead of once before all workers start. This caused only the last spec's visual data to be present in the output when running multiple specs.Committers: 1
- Wim Selles (@wswebcreation)
-
ce74703: Stop creating empty diff folders when no visual differences exist. The diff directory is now only created on disk when a diff image is actually saved, instead of being eagerly created during path preparation. Fixes #879.
Committers: 1
- Wim Selles (@wswebcreation)
@wdio/visual-service@9.1.4
Patch Changes
-
a3bc7a4: ## #1115 Respect
alwaysSaveActualImage: falseforcheckScreenmethodsWhen using visual matchers like
toMatchScreenSnapshot('tag', 0.9)withalwaysSaveActualImage: false, the actual image was still being saved even when the comparison passed within the threshold.The root cause was that the matcher's expected threshold was not being passed to the core comparison logic. The core used
saveAboveTolerance(defaulting to 0) to decide whether to save images, while the matcher used the user-provided threshold to determine pass/fail - these were disconnected.This fix ensures:
- When
alwaysSaveActualImage: falseandsaveAboveToleranceis not explicitly set, actual images are never saved (respecting the literal meaning of the option) - When
saveAboveToleranceis explicitly set (like matchers do internally), actual images are saved only when the mismatch exceeds that threshold
Committers: 1
- Wim Selles (@wswebcreation)
- When
-
a3bc7a4: ## Fix:
save*methods now always save files regardless ofalwaysSaveActualImagesettingPreviously, when
alwaysSaveActualImage: falsewas set in the configuration,save*methods (saveScreen,saveElement,saveFullPageScreen,saveAppScreen,saveAppElement) were not saving files to disk, causing test failures.The
alwaysSaveActualImageoption is intended to control whether actual images are saved duringcheck*methods (comparison operations), notsave*methods. Sincesave*methods are explicitly designed to save screenshots, they should always save files regardless of this setting.This fix ensures:
save*methods always save files to disk, even whenalwaysSaveActualImage: falseis set in the configalwaysSaveActualImage: falsecontinues to work correctly forcheck*methods (as intended for issue #1115)- The behavior is now consistent:
save*= always save,check*= respectalwaysSaveActualImagesetting
Implementation details:
- The visual service overrides
alwaysSaveActualImage: truewhen callingsave*methods directly from the browser API save*methods respect whateveralwaysSaveActualImagevalue is passed to them (no special logic needed)check*methods pass through the config value (which may befalse), sosave*methods respect it when called internally- This clean separation ensures
save*methods work correctly when called directly while still respectingalwaysSaveActualImageforcheck*methods
Committers: 1
- Wim Selles (@wswebcreation)
-
Updated dependencies [a3bc7a4]
-
Updated dependencies [a3bc7a4]
- @wdio/image-comparison-core@1.1.3
@wdio/image-comparison-core@1.1.3
Patch Changes
-
a3bc7a4: ## #1115 Respect
alwaysSaveActualImage: falseforcheckScreenmethodsWhen using visual matchers like
toMatchScreenSnapshot('tag', 0.9)withalwaysSaveActualImage: false, the actual image was still being saved even when the comparison passed within the threshold.The root cause was that the matcher's expected threshold was not being passed to the core comparison logic. The core used
saveAboveTolerance(defaulting to 0) to decide whether to save images, while the matcher used the user-provided threshold to determine pass/fail - these were disconnected.This fix ensures:
- When
alwaysSaveActualImage: falseandsaveAboveToleranceis not explicitly set, actual images are never saved (respecting the literal meaning of the option) - When
saveAboveToleranceis explicitly set (like matchers do internally), actual images are saved only when the mismatch exceeds that threshold
Committers: 1
- Wim Selles (@wswebcreation)
- When
-
a3bc7a4: ## Fix:
save*methods now always save files regardless ofalwaysSaveActualImagesettingPreviously, when
alwaysSaveActualImage: falsewas set in the configuration,save*methods (saveScreen,saveElement,saveFullPageScreen,saveAppScreen,saveAppElement) were not saving files to disk, causing test failures.The
alwaysSaveActualImageoption is intended to control whether actual images are saved duringcheck*methods (comparison operations), notsave*methods. Sincesave*methods are explicitly designed to save screenshots, they should always save files regardless of this setting.This fix ensures:
save*methods always save files to disk, even whenalwaysSaveActualImage: falseis set in the configalwaysSaveActualImage: falsecontinues to work correctly forcheck*methods (as intended for issue #1115)- The behavior is now consistent:
save*= always save,check*= respectalwaysSaveActualImagesetting
Implementation details:
- The visual service overrides
alwaysSaveActualImage: truewhen callingsave*methods directly from the browser API save*methods respect whateveralwaysSaveActualImagevalue is passed to them (no special logic needed)check*methods pass through the config value (which may befalse), sosave*methods respect it when called internally- This clean separation ensures
save*methods work correctly when called directly while still respectingalwaysSaveActualImageforcheck*methods
Committers: 1
- Wim Selles (@wswebcreation)
@wdio/visual-service@9.1.3
Patch Changes
-
2a518ff: # 🐛 Bugfixes
#1111 Pass matcher threshold to core as saveAboveTolerance
When using visual matchers like
toMatchScreenSnapshot('tag', 0.9)withalwaysSaveActualImage: false, the actual image was still being saved even when the comparison passed within the threshold.The root cause was that the matcher's expected threshold was not being passed to the core comparison logic. The core used
saveAboveTolerance(defaulting to 0) to decide whether to save images, while the matcher used the user-provided threshold to determine pass/fail - these were disconnected.This fix ensures the matcher passes the expected threshold to the core as
saveAboveTolerance, so images are only saved when the mismatch actually exceeds the user's acceptable threshold.Committers: 1
- Wim Selles (@wswebcreation)
@wdio/visual-service@9.1.2
Patch Changes
-
0a2b6d0: ## #1111 Respect saveAboveTolerance when deciding to save actual images when alwaysSaveActualImage is false.
When
alwaysSaveActualImageisfalse, the actual image is no longer written to disk if the mismatch is below the configured tolerance, avoiding extra actuals when the comparison still passes.Committers: 1
- Wim Selles (@wswebcreation)
-
Updated dependencies [0a2b6d0]
- @wdio/image-comparison-core@1.1.2
@wdio/image-comparison-core@1.1.2
Patch Changes
-
0a2b6d0: ## #1111 Respect saveAboveTolerance when deciding to save actual images when alwaysSaveActualImage is false.
When
alwaysSaveActualImageisfalse, the actual image is no longer written to disk if the mismatch is below the configured tolerance, avoiding extra actuals when the comparison still passes.Committers: 1
- Wim Selles (@wswebcreation)
@wdio/visual-service@9.1.1
Patch Changes
-
340fbe6: # 🐛 Bugfixes
#1098 Improve error message when baseline is missing and both flags are false
When
autoSaveBaseline = falseandalwaysSaveActualImage = falseand a baseline image doesn't exist, the error message now provides clear guidance suggesting users setalwaysSaveActualImagetotrueif they need the actual image to create a baseline manually.Committers: 1
- Wim Selles (@wswebcreation)
-
e4e5b5c: # 🐛 Bugfixes
#1085 autoSaveBaseline collides with the new alwaysSaveActualImage flag
When
autoSaveBaselineistrueandalwaysSaveActualImageisfalse, actual images were still saved. This patch should fix thatCommitters: 1
- Wim Selles (@wswebcreation)
-
ddf68fe: # 🐛 Bugfixes
#1084 expect(...).toMatch*Snapshot methods do not have Promise return types
The methods should be typed as promises
Committers: 1
- Wim Selles (@wswebcreation)
-
Updated dependencies [340fbe6]
-
Updated dependencies [e4e5b5c]
- @wdio/image-comparison-core@1.1.1
@wdio/visual-reporter@0.4.12
Patch Changes
-
e4e5b5c: # 🐛 Bugfixes
#1085 autoSaveBaseline collides with the new alwaysSaveActualImage flag
When
autoSaveBaselineistrueandalwaysSaveActualImageisfalse, actual images were still saved. This patch should fix thatCommitters: 1
- Wim Selles (@wswebcreation)