 Alright, hey everyone. I'm Daniel Friedman. I work on the Polymer library and for the next 15 minutes We're gonna go over how to make your Polymer elements ready to ship into production through testing methodology and infrastructure now you may be wondering what our production ready elements and In essence production ready elements are reusable. They have great documentation they have understandable code and comprehensive testing But it's a fair question to ask Why should I care about reusable elements? I always make my apps from scratch. That works well for me But the simple fact of the matter is reusable elements lower the cost of making your app If you can standardize on a set of robust highly reusable elements when building your application you will improve productivity by only working on the parts specific to your app and Here's a real-life example Google uses Polymer in over 500 applications Some are public some are not but all of them have to pass a high bar of quality for their users and In these 500 applications Google wants elements to have the same behavior buttons checkboxes dialogs sliders everything should be consistent and This means that Google wants to reuse elements across applications so that the application developers don't have to duplicate all the same behaviors and In order to meet the needs of Google and other customers Polymer has to maintain over 100 elements across three GitHub organizations With an additional copy inside of Google's internal source control system And to make sure that these reusable elements actually keep their promise to save the application developer time They have to be highly tested have great documentation and contain understandable code And that means they need to be production ready Well by this point you're probably thinking that sounds great, but how do I make my elements production ready? Well Remember this slide it isn't by accident that polymer has so many users inside of Google We learned how to make our elements production ready, and we know the tools to use they'll make your elements production ready as well And when you're building one element Then you want to share with others or you're part of a large company maintaining a huge set of elements used across tons of apps There are lots of tools at your disposal to make sure every commit is production quality and Since there's so much to talk about today, I've connected for you into this easy how-to guide And as a part of this guide, we'll be taking a look at paper checkbox That link at the bottom will take you to the repository so you can get a good look at the tools we use on our production ready elements and The main focus of this guide is really about testing and in particular these three areas of testing linting unit testing and Continuous integration Let's take these one by one and discuss why they're important. How about we start with linting? Linting tools help you spot easy errors like misspelling a variable name or forgetting a comma They can be integrated into your editor to help you spot mistakes before you even start your tests and The first tool I want to talk about is ES lint So ES lint is really an industry standard. It's extremely configurable has a broad plug-in system and Most importantly, it's compatible with our use of HTML imports by the way of the HTML plug-in Now you can configure ES lint to enforce all manner of coding style choices like braces quotes logging capitalization But this is all you need to run ES lint on polymer elements So there's a lot here. Why don't we break this down? First we extend the recommended styling guide made by ES lint This styling guide has just enough to catch syntax errors and generally bad styling But it won't force you into any particularly opinionated style Next we tell ES lint that we expect this code to run at the browser So now browser globals like document window won't cause errors when you lint Then we enable the HTML plug-in so that elements written in our default polymer style with DOM module and inline scripts will be checked correctly And finally we tell ES lint about the polymer global itself for use when we register our element And that's it pretty simple right Now you can turn on ES lint when writing polymer code and catch a wide swath of errors before you even start your tests But let's move on to polylint Polylint is a linting tool that the polymer teams created that catches polymer element specific mistakes that a tool like ES lint is not really designed to do Polylint checks that all of your dependencies are imported that your properties are defined correctly and that the syntax is correct in your data binding expressions With ES lint and polylint together you don't have to write a whole set of unit tests But you can be still production ready All right, that's everything about linting Because now we can move on to unit testing So unit testing is really what most people think about when they say testing Where you write scenarios for your code where you know the inputs and can test that the outputs mess max The expectations of your algorithms and processes and typically in web development unit testing involves one or more of these libraries mocha a test framework Chai an assertion library and Sinon.js a mocking and spying library This combination works well for thousands of projects in the web ecosystem and we in the polymer team likened as well But we were faced with a question How do we make mocha chai and Sinon.js work the best with web components in polymer? We tried a number of tools out there, but in the end we decided that we really needed to make our own And we did just that and made web component tester Or WCT for short Now we had a few requirements for WCT that no other tool really seemed to give us Obviously the first requirement was that mocha chai and Sinon.js.js should just be loaded by default We also add a few testing helpers that I'll get into a little bit later Another requirement is that we wanted to write our tests the same way we write our elements with HTML and JavaScript together In addition, we wanted to test Our elements using the same dependency mechanism that we have for writing our elements, which is HTML imports And finally we wanted to be able to run our tests both in the browser and via command line tool So why don't we take a little Deep dive and see how WCT works Here is the test runner page for our pay-per-check box element And here is where we specify the sweets we want to run You could see that we actually specify the same sweet twice. I'll be it slightly differently The second line means that we want to run that suite with native shadow DOM enabled And this is to make sure that pay-per-check box works correctly both in the polyfill and native shadow DOM implementations All right, why don't we take a look at what that basic suite contains? But first we have to load our dependencies. We'll load the web components polyfills WCT We load mock interactions, which is a testing helper. I'll give to you in a little bit And finally we load pay-per-check box And here we go a little test from the pay-per-check box suite We have mocha's sweet and test functions Here we have a chai assertion with a checkbox being checked And finally we have these two parts that probably don't look very familiar But they're part of the testing helpers that we load with WCT The first one test fixture is an element wrapper that integrates with mocha suites to easily produce and remove testing elements from the document You can put your complicated testing Like this example from paper checkbox inside of a test fixture element to create the elements Then you can test them and automatically at the end of the test. They'll be removed from the page Mock interactions is another helper that lets you easily mock user input with an understandable API You can mock mouse events, touch events, keyboard events, focus changes And you can use it whenever you have a test that requires user input to modify properties or fire an event Now the last WCT add-on I want to talk about is the accessibility suite By using Chrome's accessibility developer tools, you can automatically test some baseline accessibility for your element Like making sure your labels are readable for those with color vision deficiency Or that the RA attributes are set correctly for screen readers Now you can use the accessibility suite by specifying a text test fixture and Calling the a11y suite function with that test fixture and this will do all the work for you and give you a detailed report in your testing Now remember that I said you can use WCT via the command line The WCT command will use selenium to automatically open all the browsers on your machine Run the tests and report the results back In addition, if you use the Sauce Labs plugin, which I'll mention a little bit later You can test all of your supported browsers and operating systems from one command All right, that was a lot of stuff, but we can mark unit testing complete Because now we can talk about continuous integration Continuous integration takes all the linting and unit testing tools that we just talked about and runs them on every commit to your code repository automatically There are a lot of options out there when it comes to continuous integration services, and I really don't have time to go into all of them But I can talk about Travis CI, which the Polymer team uses for a few simple reasons First and foremost, Travis CI easily integrates with GitHub There's no complicated strings to copy back and forth or keys to remember Just a button on the Travis CI settings page and testing is now enabled for your repository Additionally, Travis is free for open source And this makes it an easy choice if you publish your element code to GitHub like we do on the Polymer team All right, now that I've told you about Travis CI, how about I show you how to configure it for your element? Here is a sample Travis configuration for a Polymer element that combines all of our testing Use this part here to make sure our VM is up to date and can run Node.js Next, we install a Firefox and Chrome Then we install a Bower, Web Component Tester, ESLint, and Polylint We install our Bower dependencies, run our linters, and Assuming the linting was successful, we tell Travis to spin up the display server and run WCT If anything fits testing, Travis will mark the run as failed and send an email to the author of the commit Now with Travis CI watching, you can be sure no untested code ever hits the repository But there's one last trick with Travis CI and WCT Remember I mentioned Sauce Labs earlier Travis CI can keep an encrypted copy of your Sauce Labs credentials and give those WCT to test all of your supported browsers on every commit All right, we're done with continuous integration Now that was a lot of stuff to cover, but you all remember it, right? Well, neither do I Setting up a robust testing tool chain is super complicated There's a bunch of tools and configurations spread out across a hundred elements and we in the Polymer team feel that pain Because we have to maintain over 100 elements and the tools to make those elements production ready So we made sure that the testing process is just as reusable as our elements Refer back to our example element, paper checkbox 90% of the testing configuration in that element is a copy and paste into your own element And now your element can reuse all the same linting, unit testing, and continuous integration tools that we use in our elements And now your elements will be just as production ready and reusable as the Polymer team's elements When your elements are reusable That saves you time and money on building your applications All right, that's it for me. If you want to learn more about improving your elements come find me at the after-party Thanks everyone. Have a great time at the rest of the summer