Open jakemac53 opened 9 years ago
In the long run, maybe it makes sense to have a package that supports testing web components? I could see it including server mocking and custom matchers (hasChild, attributeExists ,etc) to make testing web components a first class experience.
I ran across Polymer's Web Component Tester. It looks a lot like test, but it adds fixtures, sinon, and a few other things specific to testing web components. I wonder if polymer-dart might add these things in a testing library similar to what dart-lang/http does with its http.testing library.
The normal test package covers a lot of what that does, but we could possibly expose the test/common.dart
file in this package externally. We would probably need to fully flush out the sinon.js
wrapper though.
I published a package wrapping Pretender, a JavaScript server mocking library. It works well for mocking server responses for javascript-based Polymer Elements and has a smaller surface area than sinon. Might be useful if you don't want to wrap sinon.
I'm just starting to looking into porting my polymer 0.5 app to 1.0 and was curious about what was happening with the WCT in Dart. From the videos from the polymer summit it seemed rather useful but of course was in JS (bleh). A darty version would be interesting
The vanilla test package in dart gives you almost everything that WCT does, so it hasn't been a priority.
Then even better. No need to port it
Currently the iron-request, iron-ajax, and iron-form tests are actually serving static files instead of using a mock server. This only supports GET requests, and doesn't allow us to modify response headers/etc, so some tests are being skipped.
This might be a bit complicated since all requests are actually coming from the JS side of things. Might be easiest to just provide a wrapper around a JS mocking library?