AET

AET is a system that detects visual changes on web sites and performs basic page health checks (like w3c compliance, accessibility, HTTP status codes, JS Error checks and others). AET is designed as a flexible system that can be adapted and tailored to the regression requirements of a given project. The tool has been developed to aid front end client side layout regression testing of websites or portfolios, in essence assessing the impact or change of a website from one snapshot to the next.

What's the philosophy behind AET?

AET helps testers to ensure that a change in one part of the software has not introduced new defects in other parts of the software.

AET is suited for

• monitoring regression across large digital web platforms,
• managing visual changes across digital platform after changing common component (e.g. footer),
• regression tests at the end of an Hourly/Daily/Weekly/Per Sprint Completion,
• as part of an upgrade or migration process of a platform.
• client side performance tests of pages using Lighthouse extension

A typical scenario of use

1. The AET user (Developer or QA) baselines a set of components or pages with URLs as an input to the tool.
2. The CMS user changes the page component or content.
3. The ‘current baseline’ is used to compare with the ‘new version’ and the change is assessed for one of the 3 possibilities:
   • There are no changes - no involvement required.
   • There is a change but the user accepts it, which means she/he re-baselines.
   • There is a change and the user does not accept it, so she/he has to fix it.
4. AET produces a report.

AET is NOT about

• functional testing
• cross-browser testing
• usability testing
• security or server-side performance

What's inside?

AET uses several tools and frameworks that are used to check page quality in the following areas:

• Full page visual comparison using Google Chrome browser to render page and Selenium to capture screenshots inc.:
  • Hiding Page Items located by xpath or css selector,
  • Changing screen resolution (width/height setup),
• Page sources comparison.
• Page source W3C compliance with nu.validator.
• JS errors with JSErrorCollector.
• HTTP status codes with BrowserMob Proxy.
• Page accessibility with HTML_CodeSniffer.
• Page cookies comparison and modification.
• and many others ...

How to start

To setup a fully functional AET instance use one of the following:

• AET cookbook, you may run local instance using AET Vagrant.
• AET Docker images, you may run local instance as follows:
  • follow the guide here
  • assume AET_ROOT mentioned in the guide above to be equal ../aet-docker
  • this way, from the root directory of this project, you can run ./gradlew or ./gradlew deployLocal to automatically install all core bundles, core configs and core features
• AET Helm chart when you have Kubernetes cluster.

For more details on how to run AET tests, see AET in 10 minutes guide.

AET architecture

The AET System consists of 7 units:

• Client (AET Maven Plugin)
• Runner cluster
• Worker cluster
• JMS Server
• Database
• REST API
• Reports web application

Thanks to using AET Maven Plugin as a Client application, AET is easy to integrate with CI Tools like Jenkins or Bamboo.

License

AET is licensed under Apache License, Version 2.0 (the "License").

Bugs and Feedback

For bugs, questions and discussions please use Github Issues. Please notice we use the ZenHub extension to manage issues.

Documentation

• AET Wiki

Contact and Commercial Support

If you have any questions or require technical support please contact us at aet@wundermanthompson.com. Gitter Chat is a way for users to chat with the AET community. Feel free to leave a message, even if we’re not around, we will definitely respond to you when available.