mock-ajax seems very interesting, if it's working every time (I.E: doesn't depend on that the browser downloads the other element slower) it feels like a great start. With some wrappers around that one could get a pretty pleasant testing experience.
>Getting that to occur at the correct time will likely be painful - especially when supporting polyfills vs not. Lots of control here, though. Could Polymer or web-component-tester provide some nice hook that is called on the correct time? On Tue, Nov 18, 2014 at 8:30 PM, Ian MacLeod <[email protected]> wrote: > Yeah, it's not a great situation - we may end up getting some help from > the platform (unregistering or overriding elements - but there's a lot of > design considerations there: like what happens to already instantiated > elements?). Plus that'll be a while. > > There are a few hooks we can make use of now, though: > > *document.createElement()/Polymer():* Like Dane's experiments here, seems > fruitful to hook at this point. I wonder if it might be easier to declare > your stubs before importing the elements (and just swapping out the > definition entirely). Would end up with more .html suites, but seems decent. > > *Polymer.getRegisteredPrototype()/HTMLElement.getPrototypeForTag():* (for > non-polymer elements it does > a Object.getPrototypeOf(document.createElement(tag))). Alternatively, we > could use sinon to stub/mock out prototypes. Getting that to occur at the > correct time will likely be painful - especially when supporting polyfills > vs not. Lots of control here, though. > > On Tue Nov 18 2014 at 8:56:33 AM <[email protected]> wrote: > >> I'm not sure this is just a documentation thing as it doesn't look like >> there's enough hooks for Andrew's example. I've run into the same issue and >> have yet to solve it. >> >> The basic problem seems to be 3 fold: >> - elements cannot be redefined once they're registered. >> - by using declarative syntax, our element dependencies are hard coded >> in HTML >> - there's no way to reference dependent elements before they're loaded, >> thus your first chance to stub is often too late >> >> What we really need is a way to downgrade elements for the duration of a >> test. If we had this, consumers like Andrew could fire events from >> `example-api` and setup expected attributes without going through lifecycle >> methods, templates, binding, etc. >> >> Is this even possible today? >> >> I've been working on a mechanism to do this. It involves monkey patching >> `document.createElement` method and playing with prototypes as they're >> being registered to make them aware of a `stubbed` mode. It hasn't been >> fruitful yet (though I'm still moderately hopeful). >> >> Any thoughts? >> >> >> >> On Tuesday, November 18, 2014 11:28:41 AM UTC-5, Eric Bidelman wrote: >> >>> We definitely need better examples and articles around testing and using >>> mock services. >>> >>> Until then, check out Scott's POC for mocking core-ajax >>> <https://github.com/PolymerLabs/mock-ajax> and the complimentary way >>> one can do mock data <https://github.com/PolymerLabs/polymer-mock-data> >>> using components. >>> >>> We've also had luck using SinonJS <http://sinonjs.org/> for Google Web >>> Components to stub out live API calls. Example here >>> <https://github.com/GoogleWebComponents/google-calendar/blob/master/tests/google-calendar-list-basic.html#L29> >>> . >>> >>> Hope this helps! >>> >> On Wed, Nov 19, 2014 at 2:38 AM, <[email protected]> wrote: >>> >> This is a concern I have encountered as well. Especially once a component >>>> composes other components, it becomes very difficult to understand the best >>>> approach for mocking. >>>> >>>> In a project I'm working on, one component is responsible for API >>>> calls. (Let's call it <example-api>). Another component depends on >>>> <example-api> by composing it. So we have a composition like: >>>> >>>> <polymer-element name="example-component"> >>>> <template> >>>> <example-api></example-api> >>>> >>>> <!-- other code --> >>>> </template> >>>> </polymer-element> >>>> >>>> The problem this presents is that whenever I want to write a test for >>>> example-component, and I add an example-component to the page, it's going >>>> to add an example-api component as well, and if that component does any >>>> XHRs on load, I have no way to interrupt or redirect them. I want to be >>>> able to create an example-component with a* stubbed* version of >>>> example-api, but don't know how to do that. >>>> >>>> This is definitely an area where Polymer needs more discussion, >>>> documentation, and guidance. >>>> >>>> Feedback and input very welcome. >>>> >>>> On Monday, November 17, 2014 3:47:15 PM UTC-5, [email protected] >>>> wrote: >>>>> >>>>> I have looked into Polymer a lot and plan to start a small project >>>>> with it soon. >>>>> However, I'm really concerned with testing as I would like to build my >>>>> components >>>>> by the FIRST principle http://www.addyosmani.com/firs/index.html. >>>>> While >>>>> Polymer seem to solve the first four (Focused, Independent, Reusable, >>>>> Small) >>>>> very good but it seems to struggle with the last one (Testable). >>>>> >>>>> While web-component-tester provides a way of unit-testing components >>>>> it doesn't >>>>> seem to provide the answer to Mocking and thus very much limits the >>>>> testability >>>>> of components. >>>>> >>>>> Mocking HTTP, Websocket, Geolocation and similar is crucial but it >>>>> would also >>>>> be very good to be able to mock sub components so that tests of >>>>> components >>>>> that composit other components doesn't become integration tests. >>>>> >>>>> Is there anything I have missed or is this a missing part in Polymer >>>>> and Web Components? >>>>> >>>> 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/d2723c0e-c38e-49ab-8ff5-a24b013cdca6% >>>> 40googlegroups.com >>>> <https://groups.google.com/d/msgid/polymer-dev/d2723c0e-c38e-49ab-8ff5-a24b013cdca6%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> 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/fa9c84f1-151c-4fb5-be23-9704ff71b727%40googlegroups.com >> <https://groups.google.com/d/msgid/polymer-dev/fa9c84f1-151c-4fb5-be23-9704ff71b727%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- Rasmus 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/CACXJWHmdcfe%3Dj%3D5UkmKsMhK81P1oZ%3DV4U9TdxN46WswH0E%3Dq7A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
