Table of Contents
The verifications view gives you a detailed view of the results of a test run. It shows the passed and failed verifications, as well as log messages, error messages, stack traces and screenshots taken during a test run.
The results are structured by Reports, which you can select in the Batch Reports menu on the left side. The result table can be filtered based by Fails, Warnings or Passes.
This view can be reached from the Dashboard (Section 3.1) and the
Explore View (Section 3.2) by clicking on the passed (
) or failed (
) icons.
 |
A click on the Test Suite breadcrumb button will widen the selection to show verifications for each test case of this suite. Likewise a click on the batch breadcrumb button will show all the test suite runs of that batch.
The up/down arrow buttons, right of the batch breadcrumb button will switch to verifications for next/previous batch.
When a Squish result contains a video then the verification view will show a film icon next to every events part of the video. Clicking this icon will open the Squish Test Center video dialog at the time when the event (PASS/FAIL/etc) happened. The video dialog is composed of three areas:
The video player in the upper left of the dialog.
The "Last Replayed Event" area in the upper right corner.
The timeline in the bottom, displaying a time indicator and all events part of the video.
All three areas are synchronized: while the video is playing, the timeline indicator will advance and the "Last Replayed Event" will update accordingly. This synchronization between video and timeline is bidirectional, meaning:
You can advance the video and the timeline indicator/"Last Replayed Event" will follow.
You can click on the timeline or an event in the timeline, the video will then display the clicked event.
It is possible to configure the Squish Test Center video dialog via the "Configure Player" button in the bottom left. Configuration settings are as follow:
Show/Hide the "Last Replayed Event".
Overlay events toast on the video.
Show/Hide the timeline or Scenarios/Steps/Sections in it.
Table of Contents
Messages with a screenshot, failed visual and table verifications have a camera icon for a link to the image file or visual or table result file.
 |
Clicking the camera icon for a screenshot comparison failure opens a modal dialog showing the component screenshot taken during the verification. With a right mouse click on the camera icon, the actual screenshot can be saved to disk.
The dialog can be closed by either clicking the X located top/right or simply by reloading the page.
If you have setup a Repository within the Global Settings (see Setting up a repository in Squish Test Center (Section 3.12.1)) Squish Test Center will try to locate the corresponding Verification Point File from the Test Suite. If the Verification Point file can be located the expected image will be loaded as well. When a git repository is used you can specify the commit hash that a test run was based on using the .git.revision label to get the exact revision of the expected verification point file that was used for the test execution. You can use the toggle button in the bottom left corner of the dialog to switch between the actual and expected screenshot. Apart from the toggle button there is also an image slider that will help you spot differences between the actual and expected screenshots, grab the red handle with the mouse to move the slider.
If the Verification Point file can not be located or no Repository is setup the dialog will show setup instructions instead of the expected screenshot. In this case you can still use the Compare with File button to manually upload the Verification Point file to be able to compare actual and expected.
If the Verification Point file was located successfully in the linked Repository, you can use the Update expected VP button to update the expected screenshot within the located Verification Point File to the actual screenshot encountered during the test run. See Updating Verification Point Files with the Repository Integration (Section 3.4.3) for further details.
As an alternative to the Verification Point update via the Repository the Patched VP file button creates a screenshot verification point file by replacing the image in the uploaded VP with the actual one and asks for a download location. The downloaded file can replace the matching VP file used in the Squish test suite.
Clicking the camera icon for a table comparison failure, a simple row by row difference is shown. Green rows replaces the pink expected rows of the table verification point.
With a visual verification point (VVP) failure during a Squish test run, a dump of the application actual user interface (UI) is saved in the results. As mentioned, the camera icon represents the link to the failed VVP results. With a right mouse click, that result file can be saved and then later viewed with the Squish utilities uibrowser or visualvpeditor. But this dump can also be made visible in Squish Test Center, by clicking on the camera icon. A uibrowser like view will be opened in a dialog.
The left side is for the application objects, shown hierarchically. The center is for the image and highlights the current application object selected. The right side shows object properties when an application object is selected.
There are two ways to upload visual verification points. An admin user can setup repository mappings in the Global Settings, so that the verification point can be loaded automatically from the repository each time the VVP View is opened (see Repository Integration (Section 3.12)). When a git repository is used you can specify the commit hash that a test run was based on using the .git.revision label to get the exact revision of the expected verification point file that was used for the test execution. Alternatively, if no repositories are setup, a user can use the Compare with File button to manually select a visual verification point file from his local filesystem by using the upload form. Once the visual verification point file is uploaded Squish Test Center performs a comparison between the uploaded expected UI and the one from the results, the actual UI.
The letter icons in the application objects tree represent Geometry, Hierarchical, Property (or properties), Screenshot or Type errors. The geometry and/or property errors are highlighted in red within the property panel on the right side. When a property is not available because a similar object can not be found in the actual UI an N/A icon is displayed.
You can use the toggle button in the bottom left corner of the dialog to switch between Actual Visual and Expected Visual VP. Apart from the toggle button there is also an image slider that will help you spot differences between the actual and expected images of the visual verification point, grab the red handle with the mouse to move the slider. If the Verification Point file can not be located or no Repository is setup, the dialog will show setup instructions instead of the expected images.
When you are looking at the expected visual verification point you can use the Browse Errors buttons at the bottom to move to the next or previous object with an error. The hierarchy elements with errors are selected and highlighted in the visual representation of the VP file within the dialog.
If the verification point file was located successfully in the linked Repository, you can use the Update expected VP button to update the expected images and verifications within the located verification point file to the actual images and properties encountered during the test run. See Updating Verification Point Files with the Repository Integration (Section 3.4.3) for further details.
![[Note]](images/note.png) | Note |
|---|---|
Please be aware that failed wildcard, regular expression and range checks are replaced by simpler checks that verify basic equality to the encountered values in the actual snapshot. |
As an alternative to the verification point update via the Repository the Patched VP file button can be used to download an updated verification point file, that can be used to manually replace the verification point file within the test suite.
Finally the VVP view can be closed by either clicking the X located top/right or simply by reloading the page.
Table of Contents
If a repository integration is enabled, verification point dialogs can show the expected verification point from the mapped Repository. If there is a difference between the actual result snapshot or screenshot and the data stored in the verification point, you can use the Update expected VP button to update the file in the repository to match the actual result.
For verification point files from a Filesystem Repository the update mechanism simply replaces the verification point file on disk. When pressing the Update expected VP button a confirmation dialog is displayed where you can verify the path within the repository that will get replaced.
| Note |
|---|---|
The Filesystem Repository has no way to track changes over time, therefore once you update the verification point file you will no longer be able to view the differences for the specific test run the changes originated from. |
For verification point files from a Git Repository the update mechanism bases the update either on the currently checked out branch head, or on the git commit hash supplied via the .git.revision label. The updated verification point file is not only added to the repository folder, a local commit is created as well.
When pressing the Update expected VP button a dialog opens where you can specify a commit title and description.
The updated verification point file is committed to the default branch supplied in the repository settings (see Git repository settings (Section 3.12.3)) or the branch head of the branch supplied via the .git.branch label. It's possible that the verification point file was already updated by someone else or at a previous point in time, in this case the submit button will be disabled and an info message is displayed.
In the repository settings you can also specify whether the update mechanism should also push the commit to the remote of the repository. If you enable the option Push to remote when updating VP file (see Git repository settings (Section 3.12.3)) the update mechanism will first pull all changes from the remote and then push the local commit.
The Update mechanism uses script files from the Test Center directory testcenter/config/scripts/git
to update the repository. Windows uses update.bat (with push & pull) and
update_local.bat(without push & pull), and Mac/Linux uses update.sh and
update_local.sh. These script files can be edited to adjust the git workflow if needed.
Test Center does not provide any advanced conflict resolution features, so in some error cases you might have to
manually resolve conflicts within the repositories linked to Squish Test Center. If you encounter general issues with
the git workflow we intended you could try to adjust the scripts found in
testcenter/config/scripts/git to your needs.
When there is issues related to the remote state of the repository it might make sense to simply turn off the
remote features and do the pushing and pulling manually (see Push to remote when updating VP file
setting in Git repository settings (Section 3.12.3)).
Following is a list of potential causes for update errors.
As one of the first steps in the verification point file update process Squish Test Center needs to checkout the branch
that the updated VP should be placed in. The branch is determined by checking the .git.branch label (if that label
is not provided the Default Branch setting in the Git repository settings (Section 3.12.3) is
used instead). The update script only calls git checkout when the current branch of the repository differs from the
target branch.
Some common reasons the git checkout might fail include:
The branch name provided via the .git.branch label or the default repository settings might be incorrect.
The branch might only exist in a remote repository, the update script does not call
git fetchso you might need to call that manually.In case the repository has several remotes, the branch name can be ambiguous and might require the specification of the remote/branch.
There might not be any remotes specified for the repository. You can resolve this by specifying a remote (manually outside of Squish Test Center), disabling Push to remote when updating VP file in the repository settings ( Git repository settings (Section 3.12.3)) or by adjusting the update scripts in
testcenter/config/scripts/git.There might be conflicting changes on the remote, you would have to resolve this manually outside of Squish Test Center.
There might be untracked files in the local repository directory, you would have to resolve this manually outside of Squish Test Center. You should make sure that the linked repository directory is exclusively used by Squish Test Center.
The updated verification point file is placed in a temporary folder and later copied into the repository directory by the update script. This error can occur when the system user running Squish Test Center does not have permissions to copy files into the repository directory.
While updating the verification point file the update script will call git add path/to/vp/file.
Ensure the file does not meet exclude rules in .gitignore and .git/info/exclude.
While updating the verification point file the update script will call git commit -F to create a local commit.
If this fails it might be due to a git commit-msg hook that is enforcing a specific format on commit messages.
There is no difference between the updated verification point file generated by Squish Test Center and the current state of the repository. This might happen when the verification point has already been updated by someone else.
After creating a local commit the update script will try to call git push. Some common reasons for that
to fail include:
There might not be any remotes specified for the repository. You can resolve this by specifying a remote (manually outside of Squish Test Center), disabling Push to remote when updating VP file in the repository settings ( Git repository settings (Section 3.12.3)) or by adjusting the update scripts in
testcenter/config/scripts/git.There might be conflicting changes on the remote, you would have to resolve this manually outside of Squish Test Center.
The remote repository might have been updated in the meantime, in some cases it might be sufficient to simply retry the update.