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] <javascript:>> 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] <javascript:>. >> 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. For more options, visit https://groups.google.com/d/optout.
