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.

On Thursday, 22 May 2014 10:56:38 UTC+1, [email protected] wrote:
>
> 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.
>
> On Wednesday, 21 May 2014 00:35:15 UTC+1, Rob Dodson wrote:
>>
>> I just spent some time on this and here's what I have to show:
>> https://github.com/robdodson/polymer-karma-test
>>
>> 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!
>>
>> On Tuesday, May 20, 2014 7:59:37 AM UTC-7, keithamus wrote:
>>>
>>> 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.
>>>
>>> On Tuesday, 20 May 2014 15:47:49 UTC+1, Rob Dodson wrote:
>>>>
>>>> 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.
>>>>
>>>> On Tuesday, May 20, 2014 7:37:29 AM UTC-7, keithamus wrote:
>>>>>
>>>>> I've set up a reduced test case on 
>>>>> Github<https://github.com/keithamus/polymer-karma-test>to demonstrate the 
>>>>> problem I'm having.
>>>>>
>>>>> Essentially, Karma <http://karma-runner.github.io/> 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
>>>>>
>>>>

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/91aa0142-dd4f-4a11-b688-2f509ebb5607%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to