You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
schlessera opened this issue
May 8, 2020
· 4 comments
Labels
P0High priorityTestingIssues related with Unit, E2E, Smoke, and other testing requirements/needsWS:PerfWork stream for Metrics, Performance and Optimizer
We're close to a point where we practically have feature parity with non-AMP in most use cases.
Because of that, there are a few scenarios in the plugin by now that could highly benefit from automated visual regression testing:
Non-AMP to AMP conversion
AMP to optimized AMP conversion
Theme conversion
This can be done more or less efficiently with any of the popular visual regression testing tools like BackstopJS or AyeSpy with the current process:
Use a WordPress reference site and run snapshots of test URLs that are then saved as reference images. This means we don't have to maintain a set of reference images, we just consider WordPress without the AMP plugin to be the canonical source.
Install and activate AMP plugin.
Add filter to disable optimizer.
Create snapshots of test URLs, compare with reference images and report on results.
Make snapshots from 4. new reference images. This way, we can compare the optimizer separately.
Remove filter to disable optimizer.
Create snapshots of test URLs, compare with reference images and report on results.
Benefits:
Easy to detect regressions when changing the logic to process the markup or the styling, saving peer review time.
Easy to pinpoint issues where we still fail to provide feature parity, increasing overall robustness of our turnkey solutions.
Quantitative assertion of how close we are to making AMP fully transparent for WordPress users, allowing use to market these qualities with confidence.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
Implementation brief
QA testing instructions
Demo
Changelog entry
The text was updated successfully, but these errors were encountered:
schlessera
added
the
Testing
Issues related with Unit, E2E, Smoke, and other testing requirements/needs
label
May 8, 2020
Should we expand this to having both visual and performance regression testing? The former to track AMP Content generation (and the visual impact of the optimized content), and the latter to track core web vitals and other metrics. We can also split it into separate issues.
P0High priorityTestingIssues related with Unit, E2E, Smoke, and other testing requirements/needsWS:PerfWork stream for Metrics, Performance and Optimizer
Feature description
We're close to a point where we practically have feature parity with non-AMP in most use cases.
Because of that, there are a few scenarios in the plugin by now that could highly benefit from automated visual regression testing:
This can be done more or less efficiently with any of the popular visual regression testing tools like BackstopJS or AyeSpy with the current process:
Benefits:
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
Implementation brief
QA testing instructions
Demo
Changelog entry
The text was updated successfully, but these errors were encountered: