Community status of jqUnit.js
obara.justin at gmail.com
Sat Jan 19 00:31:31 UTC 2013
I guess I have three points to bring up.
Do we have users who only use jqUnit but not the framework?
Should we add a build module for jqUnit?
Will this make our tests more brittle, since changes to the framework could potentially affect it?
I personally don't know of anyone using jqUnit exclusive of the framework, so this may not be an issue. In regards to the build module, I think it should be there either way. I found it a bit annoying for Decapod that I would have to create a custom Infusion build and then have to copy and paste jqUnit. However, for point 3, I think this is a big issue. I don't know what an ideal way around this would be though. Any thoughts on this?
On 2013-01-18, at 4:40 PM, Michelle D'Souza <michelled33 at gmail.com> wrote:
> This seems reasonable to me. Justin, do you have any concerns with introducing a dependency in jqUnit on our core framework?
> Michelle D'Souza
> Senior Inclusive Developer
> Inclusive Design Research Centre, OCAD University
> On 2013-01-17, at 4:18 PM, Antranig Basman wrote:
>> Long ago (perhaps even as early as 2006) we embarked on an XUnit-style wrapper for the QUnit testing framework which has since come to be managed by the jQuery community. At the time, this was on the basis of increased familiarity by Java and C++ developers with the XUnit-style - for better or worse, we have accumulated a huge codebase of tests expressed in this style, as well as a number of utilities which we find useful in our community (for example, for comparing trees of Fluid Renderer components).
>> As part of the rationalisation work required by http://issues.gpii.net/browse/GPII-77 and http://issues.fluidproject.org/browse/FLUID-4886 it was found to simplify the code loading idiom considerably of our jqUnit and associated platform support libraries in the browser and node.js environments to give it a dependence on our core framework file Fluid.js. Over the years, the position of jqUnit has become progressively clearer as something we could not expect to reasonably offer or support to groups outside the Fluid community - but I am sending this mail to check on consensus for this point - the pull requests in question are under review now, and so this de facto decision could be reversed if we decided that we really wanted to prepare and support jqUnit as something of wider interest outside Fluid.
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work