Testing

[adam-lynch]

The Grunt example linked in the readme isn't very clear for me. I can only assume that if it wasn't properly UMD, then loads of the underlying tests would fail, which isn't ideal really.

It would be great if there were solid tests (in this / a separate project) for testing if everything is exported correctly, etc. Having tests properly documented, maintained and used would only increase confidence. Then there could be build system specific plugins / projects which just wrap / use these tests (perfect for CI).

What do you think? I'd love to contribute but I wouldn't be 100% sure what exactly sure be tested and what all the edge cases are.

[adam-lynch]

cc @phated, @alexlawrence, @ForbesLindesay (authors of some UMD wrappers)

[alexlawrence]

cc @bebraw as I will not be maintaining grunt-umd anymore

[bebraw]

+1 Having tests available would be just great.

Now the big question is how to write those. Do you run them against real browsers, check AST, mock an environment and test against that or what?

[adam-lynch]

@bebraw I guess we could mock an environment, I'm not sure really.

I'm thinking the AST route wouldn't be best. We shouldn't care how the code is layed out (e.g. if it's if(window) if(window.define) or window['def' + 'ine'] ? ... : ...), but that it does what it should. Then anyone can quickly come up with a new way of handling UMD / a completely new pattern. The problem with some of the existing tests out there are they check that code looks like an explicit pattern.

[szepeviktor]

Is travis+saucelabs OK fo you?
http://docs.travis-ci.com/user/gui-and-headless-browsers/
https://saucelabs.com/opensauce

[bebraw]

@adam-lynch I have some preliminary Saucelabs tests at libumd. I am certain the tests can be improved a lot but even this is better than nothing and can be built upon if there is interest.