"What is Google’s Polymer Project?" This is typically what I hear when I begin talking about this brand-new web component technology my company is using to implement a responsive web application. The Polymer Project is a library for creating web components, which align with W3C standards and provide a set of features for creating custom HTML elements. It is designed to make it easier and faster to make custom HTML elements that work, like standard DOM elements. The Polymer elements can be similar to standard DOM elements. It is important to understand that these custom HTML web components do not play nicely with the standard browser testing tools (a.k.a. Selenium) which is just the reason why we need to discuss the testing strategy for a Polymer web development project.
testing your elements
The Polymer team has created a testing framework called Web Component Tester (WCT), which wraps around Mocha, Chai, Sinon, Selenium and more. The WCT runs test suites through browsers using Selenium, and also has built-in Sauce Labs integration for remote execution. I would caution you that the Polymer WCT framework is built on top of many third-party tools, and some of these frameworks might not be able to fully test custom web components when the browser is using the native Shadow DOM.
Here is a brief description of custom web components and Shadow DOM:
Custom Web Components enable the author to define and use new types of DOM elements in a document.
Shadow DOM combines multiple DOM trees into one hierarchy and illustrates how these trees interact with each other within a document, thus enabling better composition of the DOM.
If you are planning to use both Selenium and Appium for Polymer web applications, you need to be aware of Polymer Shadow DOM. Browsers often encapsulate this internally. Polymer custom elements are rendered as unreachable in the DOM subtree. Based on my experience, Selenium has struggled to locate these custom elements. It's possible to find or build a solution for third-party testing frameworks (like Selenium and Appium) to locate custom elements. Polymer uses polyfills (from webcomponents.org) which are lightweight, work well and operate on the following supported browser versions below:
The test strategy for a Polymer Project slightly differs when compared to other front-end tech stacks. This approach heavily focuses on developing unit tests for web components and executing them across mobile, tablet, and desktop browsers. Polymer's command-line interface (CLI) tool includes a test runner WCT that provides a comprehensive solution for running a suite of unit tests inside real browsers using Selenium. The CLI tool also has built-in support for Sauce Labs testing. The development of unit web components testing allows us to continue to execute against Safari, Chrome, and Firebox browsers. It enables the team to add the unit tests to be part of the CI pipeline. It integrates nicely with Mocha and Chai for assertions, and Sinon for mocking.
My thoughts on a testing strategy for Polymer:
The test pyramid for Polymer Projects needs a solid foundation of unit tests for web components, since the current Selenium Webdriver and Shadow DOM don't play nicely together.
How can we handle integration testing with remote data? The WCT includes the Sinon JS framework, which allows us to create mock servers returning test-set JSON.
We need some level of automated responsive/adaptive integration testing for components, functional end-to-end testing, and visual checkpoints using Applitools.
Conclusion
It's important to understand the behavior of the technology stack before diving head-first into a testing strategy. Don't assume your existing automated testing strategies will work smoothly with the new technology stack. Take the time upfront to ensure your existing or new testing strategy will be reliable, scalable, provide adequate test coverage (testing pyramid), and meet your goals. Before creating an automation strategy, understand the goals and methods to accomplish the task. If the goals and methods are unclear, I recommend checking out this article about automation strategy written by Paul Grizzaffi (@pgrizzaffi).
The Polymer Project will not be the last technology stack to challenge us or reshape our automated testing strategy. We need to be proactive and continue to seek ways to move faster with a mindset focused on quality first.
References:Unit Testing with Web Component Tester - Polycasts #36 (Video)Polymer Testing Your Elements Testing Polymer Web Components - The Polymer Summit 2015 (Video)
Greg Sypolt (@gregsypolt) is a Senior Engineer at Gannett – USA Today Network and co-founder of Quality Element. He has spent most of his career working as a developer in test— concentrating on automated testing for web browsers, APIs, mobile, and more. He is focused on the research, creation, and deployment of automated test strategies, testing frameworks, tools, and continuous integration. He’s passionate about #TestAutomation #TestCoverage #ContinuousIntegration and #DevOps.
