NEST Workflow
My first big Gartner project was to create an end-to-end testing platform for NEON, our shiny new Angular application. We built NEST: Neon End-to-end System Tests.
Don’t Repeat Yourself
We wanted to avoid some of the mistakes made in the past with the platform that tests the legacy Admin application the advisor team uses in-house. Some of the issues we wanted to avoid include:
- scalability issues: adding a spec involves updating the underlying framework
- page objects are large and unwieldy
- intricate looping and specs included in shared page objects make it hard to tell what exactly failed
- mocks and UI maps are not easy to access
- performance issues
Approach
We decided to favor self-documenting tests and OOP over DRY page objects with magic helpers in the new framework. By avoiding validation in shared page objects, we can tell exactly what spec failed. Part of the reason this was done in the previous framework was to avoid code duplication. We tackled this issue by choosing also to favor testing (reusable) components instead of testing at the page level. In this way we can keep our code DRY as well.
We improved performance by composing smaller specs into suites so that we can test them in parallel. We also built in support for command-line arguments to specify browser and suite, which helps limit the number of tests run at any one time.
Implementation
We decided to write the testing platform in TypeScript for a few reasons. NEON, the application under test, is also written in TypeScript, so NEON developers would be able to contribute to end-to-end testing. This also allows us to put up some guardrails for the primary contributors: the QA team. TypeScript allows interfaces and classes through which we encoded a contract of usage. It’s strongly typed, so those rules are enforced. We added TSLint to the Git pre-commit hook to catch errors and auto-fix many.
We also normalized configuration, mocks, and UI map data to make them easier to read, use, and consume. We removed sensitive information from the repo and hid it in a .env configuration file. We leveraged NPM scripts to improve CLI usage.
Additional features included:
- environment: supports more environments than the previous framework, easier to manage
- url: easily manage protocol, domain, endpoints, basic auth, and query strings in the application
- ui map: gleans the good parts of the page object model while leaving behind the bad
- product store: a repository with get/filter methods to easily test specific product pages
Test benchmarking revealed our new framework is nearly 12x faster than the old application. Just as important, the new platform scales and is now far more maintainable.