未加星标

Polymer Web Component Unit Testing

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

"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:


Polymer Web Component Unit Testing

source: https://www.polymer-project.org/1.0/docs/browsers

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.

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: HTMLChrome
分页:12
转载请注明
本文标题:Polymer Web Component Unit Testing
本站链接:http://www.codesec.net/view/533881.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(14)