Hi Colin, The unit tests are written using Jasmine, I have a gulp task that runs them (using phantomjs) whenever the code is saved in the editor for instant feedback. This is something we started doing on a previous project and I wanted to make sure we got the same advantages with this new project. I mock out the polymer and browser parts of the interface in the test specs, this helps keep the tests fairly simple and fast running.
Separating the code from the dom/template/polymer code helps to make the logic side of the application much easier to see. I tend to have 3 files in each element folder, one containing the mark-up, one the styling and the last containing the majority of the JavaScript. Vulcanizing it turns it back into a single file so having a large number of files isn't a problem. The only slight downside to the above approach is a small amount of duplication between the Polymer side of the element and the JavaScript module, any methods exposed by the element are simply thin wrappers around calls into the module. I don't see this as a huge problem though as the elements have fairly simple interfaces so it isn't particularly onerous. Rob On Tuesday, 8 March 2016 16:30:53 UTC, Colin Cannon wrote: > > HI Rob, I am interested to hear how you do your unit tests and how > splitting the js from the html makes it easier. > > On Monday, March 7, 2016 at 12:28:30 PM UTC-8, Rob Stone wrote: >> >> Just looking for some feedback on the approach I am taking for an >> application at work. >> >> The application in question is an administration console for one of our >> products, it needs to be easily extendible so that new modules can be added >> in for different parts of the product. >> >> I'm creating the shell/framework using vanilla JS & Polymer (not using >> Material Design as we have our own look and feel). I'm using behaviours to >> define the various interfaces that the plugin modules support with each >> behaviour having a handler for the registration event that injects it into >> the correct part of the shell. >> >> The shell consists of several elements with a master element acting as a >> mediator, I adopted this approach after watching one of the excellent >> polyconf videos. >> >> The plugins are defined as Polymer elements and are loaded dynamically as >> each user of the system will have access to potentially different plugins. >> >> The framework supports i18n by dynamically loading and injecting language >> specific JSON files on start up. >> >> On the Polymer side, I'm splitting the style and JS into separate files >> to try and give a bit more structure than dumping it all in the .html file, >> this primarily helps when explaining the code to non-Polymer fluent devs. >> It also allows me to have continuously running unit tests in the dev >> environment. I'm planning on using web component tester for integration >> level tests as it is a little too heavy weight for unit testing. >> >> Traditionally we style our apps using LESS, however I've found that CSS >> custom properties have removed the need for this. >> >> The application shell is Vulcanized, and each of the plugin modules are >> also Vulcanized. This is giving me nice small file sizes and minimal >> network overhead :) >> >> I deliberately avoided using Polymer Starter Kit, as although it is great >> for getting you up and running quickly, I wanted to be able to investigate >> different solutions without being too hampered by an existing framework. >> >> One of my aims when putting this framework together was to try to keep as >> close to 'html as the framework' as possible. Polymer behaviours were too >> tempting to ignore as they give a really nice way of defining the plugin >> interfaces and I am using Polymer helper methods and data binding. However >> compared to the angular/react solutions being used elsewhere in the company >> this application feels far closer to a vanilla JS solution. >> >> My adhoc testing so far shows that the application performs well across >> all the desktop browsers we support (Chrome, Firefox, IE) and Safari on >> iPad. >> >> I'm very satisfied with how easy it has been to produce a robust solution >> in a small amount of time using Polymer, it's good to finally be using it >> in anger after spending the last year or so playing around with the >> technology. It certainly feels production ready to me now and I plan to >> make as much use of it as possible in the future. >> >> Cheers >> Rob >> >> Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/e11c3cf4-0870-424b-85f3-c8f108c4a650%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
