Community status of jqUnit.js

[Justin Obara]

On 2013-01-21, at 10:56 AM, Colin Clark <colinbdclark at gmail.com> wrote:

> Hey all,
> 
> On 2013-01-18, at 7:31 PM, Justin Obara <obara.justin at gmail.com> wrote:
> 
>> I guess I have three points to bring up.
>> 
>> 	• Do we have users who only use jqUnit but not the framework?
> 
> Personally, I am not keen on supporting jqUnit independently from Infusion. I just don't think it makes sense  to use without Infusion and IoC, since there just isn't much there--a few utilities and a whole layer of xUnit-style silliness that we've all become hopeless dependent on. What's the benefit for your average developer? My guess is, as a result, no one is depending on it alone.
> 
> Back in 2007, there was someone who had adopted jqUnit and created a mock testing environment on top of it, but as far as I know it hasn't been active or in use since then.
> 
> If we want to be very prudent, we could ask the user list, but I'd be surprised if there are any active, non-Infusion clients of jqUnit.

I think we're pretty much in agreement on this point, and I suppose this conversation on list probably takes care of any due diligence that we need.

> 
>> 	• Should we add a build module for jqUnit?
> 
> In order to provide it as an optional tool for developers who are using Infusion? That way, they would be able to test their apps with jqUnit, too, without having to grab it from our Git repo? I think it's a reasonable idea, assuming we want to offer it as a supported tool. I would, for example, likely pick it up and use it in Flocking.

Yes this is basically what I was thinking. 

> 
> But I wonder if perhaps distributing jqUnit via npm might be as useful as with our Builder?

I don't really have much experience with the node.js world, but I think it would also make sense. Although I thought with our current approach the infusion package would have been able to create it based on our build modules, or perhaps you mean something more. 

> 
>> 	• Will this make our tests more brittle, since changes to the framework could potentially affect it?
> 
> Can you elaborate on the kinds of brittleness that you're concerned about? Perhaps some examples?
> How, specifically, is it a big issue?

I'm not sure I have any specific concrete examples. I probably don't know enough about the inner workings of either the framework or the jqUnit extension to really be able to do that. I can try to make some hypothetical ones, hopefully they  may lead to further thoughts and start to tease out some actual potential issues, or prove that the fear is unwarranted. 

I suppose the everything is broken cases should be pretty obvious to someone making a change to the framework, so those should be less of an issue. I'd be more worried about the more subtle ones that may cause some tests to appear to work or not just because of some framework issue. Maybe a change in the framework might affect the jqunit extensions sequencing of tests, merging of options, or instantiation of components, component creation order or something else. 

The obvious worry is that because the debugging is so difficult right now, if something does arise, it will be hard to track. At the end of the day I just want to make sure that we have thought things through and have our bases covered so that we can prevent our tests from becoming unreliable. If we can do that, I'm fine with this dependency.

Thanks
Justin