List view
Currently Quilla relies on the contents of the XPath or URL to make validations, which makes sense for data-driven uses such as fetching data from websites and creating outputs, or verifying the existence of elements/their contents. However, one critical element of UI testing is ensuring that the look of certain elements does not change between runs unexpectedly. As such, a 'Visual Parity' validation type would enable Quilla to compare screenshots, and fail the test if a change has been introduced. The VisualParity validation type would work as follows: - The VisualParityValidation object would create an initial screenshot of the XPath given - The VisualParityValidation object would get the baseline image, if it exists, from a plugin hook - The plugins would evaluate if they have enough data to search for the baseline ID - If yes, it would return the image (if present), and raises an exception if it is not found - If no, it would return None - With the new image and the baseline, the VisualParityValidation object would compare the two and produce the output delta - The VisualParityValidation object would send the delta, with an updated BaselineID, to the plugins for storage - The plugin, if okay to run, would store the image and return the path/link/whatever to the newly stored image - The VisualParityValidation object would then add the path to the delta, the path to the treatment image, and the path to the baseline to the report
No due date•9/10 issues closed