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? Thanks Justin On 2013-01-18, at 4:40 PM, Michelle D'Souza <[email protected]> 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. >> >> Cheers, >> Antranig >> _______________________________________________________ >> fluid-work mailing list - [email protected] >> To unsubscribe, change settings or access archives, >> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
