Polymer failing in Karma with inheritance

271 views
Skip to first unread message

keithamus

unread,
May 20, 2014, 10:37:29 AM5/20/14
to polym...@googlegroups.com
I've set up a reduced test case on Github to demonstrate the problem I'm having.

Essentially, Karma isn't working with Polymer - during running of the tests, Polymer complains about duplicate elements being registered, however, in Karma's debug mode, and in fact outside of the test environment, the polymer elements work fine.

I realise that this sounds pretty much like a Karma bug, but this seems like a good place to get the ball rolling at least.

The error from Polymer is as follows:
  Error: DuplicateDefinitionError: a type with name 'a-element' is already registered
  at /Users/keith/Projects/polymer-karma-test/main/bower_components/platform/platform.js:15

Feel free to pull the repo and have a play

Rob Dodson

unread,
May 20, 2014, 10:47:49 AM5/20/14
to polym...@googlegroups.com, ad...@keithcirkel.co.uk
I know the Polymer team uses a plugin they wrote for Karma to run tests in iframes. You can check it out here:
https://github.com/Polymer/core-tests/tree/master/tests

We haven't written a ton of guidance around it (though I believe Addy is working on an article) but the tools folder in that repo might be enough to get you started. Maybe give it a shot, see how far you get, and we can keep this thread going to work through any issues.

keithamus

unread,
May 20, 2014, 10:59:37 AM5/20/14
to polym...@googlegroups.com
Seems a shame to have to plug (read: hack) around Karma, when the default (read: easier to set up) usage gets 99% of the way there. Not to balk at your efforts at all - I just think it seems like tackling this problem seems preferable to having to inject iframes with custom scripts.

Rob Dodson

unread,
May 20, 2014, 7:35:15 PM5/20/14
to polym...@googlegroups.com, ad...@keithcirkel.co.uk
I just spent some time on this and here's what I have to show:

I think the duplicate error was caused by how you were including the components directory in karma.conf.js. I saw two entries for components, so I reduced it to one and set included to false. In each suite I have a before block where I setup the link tag for my element and listen for its load event before jumping into the individual tests.

Also take a look at test/karma-loader.js where I load polymer.html and listen for the polymer-ready event before kicking off mocha.

So, you can try to use this approach to see how far you get with it. The nice part about the iframe work around is that you don't have to manually manage the link elements yourself and it reduces possible prototype pollution issues but if you prefer this style that's cool too :)

Keep in mind, Karma was invented in an era before Web Components even existed and making testing web components easy is not one of their design goals. At present, there isn't a really great tool for testing Web Components because they're so new. We hope that story changes in the future, but it will take time for us to get there.

Hope this helps!

ad...@keithcirkel.co.uk

unread,
May 22, 2014, 5:56:38 AM5/22/14
to polym...@googlegroups.com
Rob,

If you closely with my karma.conf, it is not actually loading two lots of the components. The first line referencing the components directory (https://github.com/keithamus/polymer-karma-test/blob/master/karma.conf.js#L13) loads in all .html files (which Karma knows to use <link rel=import> for), the second line referencing the components directory (https://github.com/keithamus/polymer-karma-test/blob/master/karma.conf.js#L15) loads in all of the test.js files, and finally the last line (https://github.com/keithamus/polymer-karma-test/blob/master/karma.conf.js#L20) LOOKS like it may load in all the files again, but doesn't - because include is set to false.

It seems in your solution you've just moved all of the <link rel=imports> from being generated by Karma, to doing so manually in the tests. While this seems to work, its still IMO as bad as the iframe solution - its not **solving** anything, just working around it. I'm sure there is a solution which requires no intervention from tests themselves.

Karma does seem to work when loading these elements in, it does everything correctly (using <link rel=import>). The debug view actually works and you can see the tests passing in the console, so I don't necessarily think that Karma needs to be worked around - it smells more like a bug to me. While I understand Karma was invented before webcomponents, I can't actually see why web components shouldn't *just work* in Karma, if you could elaborate on this with specifics that'd be great.

ad...@keithcirkel.co.uk

unread,
May 22, 2014, 9:13:55 AM5/22/14
to polym...@googlegroups.com, ad...@keithcirkel.co.uk
I've now discovered the issue with this. When Karma runs in it's context mode, it appends the file hash to the link as a query param, which look like this:

<link href="/base/main/components/a/a.html?a6a4ee4791f8cd22cca1d76284ef18e9cfe95cbe" rel="import">
<link href="/base/main/components/b/b.html?a59384009c80baff4e8de4896cb8a6bf8e192890" rel="import">
These extra query params seem to be breaking Polymer's dependency resolution logic. We can simplify all of this by removing Karma, and just on a static HTML page with any old additional query params in the link elements, we can break dependency resolution.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages