polymer unit test mocking dependencies

Question

Im just starting on polymer. Im trying to unit test a custom element that has dependencies and I would like to fake/mock these out. I've found Scott Miles recommendation on how to mock the core-ajax implementation. I thought I could follow that pattern easily but this only works as long as my element does not import the about to be mocked (core-ajax in this case) element. If it does import it, then when the test tries to run I get

'Uncaught NotSupportedError: Failed to execute 'registerElement' on 'Document': Registration failed for type 'core-ajax'. A type with that name is already registered.'

If I could do something like document.unregister the core-ajax element and import it again in my test, Id be a much happier dev!!! Polymer is awesome but if I can not unit test it, then it presents major risks (at least when building an app that will need to be maintained/changed)

How are you guys working around this? I've been digging into Polymer and PolymerLab elements repo and most of them lack tests. So far I;ve not found much reference on how to do it.

Thanks for the help!

Santiago

Scotts' recommendation was:

Instead of importing core-ajax/core-ajax.html, create your own core-ajax element.

<polymer-element name="core-ajax" attributes="response">
<script>
  Polymer('core-ajax', {
    attached: function() {
      this.response = ['a', 'b', 'c'];
    }
 });
</script>
</polymer-element>

Obviously, this is just an example, the actual implementation depends on the desired mocking behavior.

This is just one way to solve it, there are many others. I'm interested to hear what you find (in)convenient.

Answer 1

This question is a little old. Figured I'd provide an update since this is a pretty common situation.

Polymer CLI is the recommended approach for unit testing Polymer elements. The underlying library that it uses for testing is called web-component-tester (WCT). WCT has support for stub elements. Basically, if one of your tests relies on another element to return data, you can create a stub of that element that always returns consistent data.

JS in the unit test code for specifying the stub element:

setup(function() {
  replace('paper-button').with('fake-paper-button');
});

Element to be tested:

<dom-module id='x-el'>
  <template>
    <paper-button id="pb">button</paper-button>
  </template>
</dom-module>

At test runtime, the content template would be stamped out as:

<dom-module id='x-el'>
  <template>
    <fake-paper-button id="pb">button</fake-paper-button>
  </template>
</dom-module>

https://www.polymer-project.org/1.0/docs/tools/tests#create-stub-elements

Answer 2

You can try registering it imperatively with js or extend every single element you are testing and override its properties or methods you want to mock. i think that is just about it. It's like my google-map custom element, i import the google-map and change stuff around like so:

<polymer-element name="core-gmaps" attributes="lat long mapzoom markerlat markerlong markertitle" extends="google-map">
    <template>
        <style>
        :host{
            width: 100%;
        }
        #vivaMap {
            display: block;
            height: 100%;
            width: 100%;            
        }
        </style>
        <google-map id="vivaMap" latitude="0" longitude="0" zoom="18">
            <google-map-marker id="vivaMarker" title="" latitude="0" longitude=""></google-map-marker>
        </google-map>
    </template>
    <script>

  Polymer("core-gmaps",{
    ready: function(){

        var map = this.$.vivaMap;
        map.latitude = Number(this.getAttribute('lat'));
        map.longitude = Number(this.getAttribute('long'));
        map.zoom = Number(this.getAttribute('mapzoom'));

        var mapMarker = this.$.vivaMarker;
        mapMarker.latitude = Number(this.getAttribute('markerlat'));
        mapMarker.longitude = Number(this.getAttribute('markerlong'));
        mapMarker.title = this.getAttribute('markertitle');
        /*map.addEventListener('google-map-ready', function(e) {
            console.log('Map loaded!');
        });*/
    }
  });
  </script>
</polymer-element>

I am still not sure if it was worth it professionally (i may end up not using it), but was totally worth it intellectually. learned some nice stuff. since i'm extending google-map it gets registered once and only once.

EDIT:
in my case i used the ready event because i couldn't manipulate the map per se without it being at least ready. but you can choose the event callback from the lifecycle methods.
The list is here.
PS.:Yes, i didn't use data binding because i couldn't. The google map api was complaining about it being NaN so i had to cast it.