Collaboration with Intern

[jzaefferer]

We have a ticket to document integration with CI tools, including intern, though I wonder if that is really a good investment of our time. Elsewhere @csnover wrote:

I’ve actually got a mostly-working branch with a full* QUnit API compatible interface so, with only a small amount of work to address the TODOs (probably only a day or two of work?), you should be able to drop existing QUnit tests into Intern by wrapping them with define([ 'intern!qunit'], function (QUnit) { }) and have them Just Work.

(And then, fingers crossed!, I can convince team QUnit to come over & help me get cool new stuff into Intern more quickly :)))

I still haven't gotten around to actually trying out Intern myself. We're going with Intern to test PEP, but otherwise there's nothing happening, as far as I know.

@leobalter @JamesMGreene @Krinkle did one of you have more exposure to Intern? Or do you have interest and time to look into that?

@csnover apart from what I quoted above, is there something we could or should work on asap for better QUnit into Intern integration? What do you have in mind beyond that?

[JamesMGreene]

Just so we're all clear:

From my talks with @csnover, it is my understanding that the code for the QUnit interface for Intern lives 100% within Intern. It neither depends on nor utilizes any QUnit assets, it only mimics the API (so there isn't any actual integration to speak of). Also, I think that writing QUnit tests for Intern would still require that test authors are using Intern's AMD configuration (or generating such wrappings).

(And then, fingers crossed!, I can convince team QUnit to come over & help me get cool new stuff into Intern more quickly :)))

I'm believe this remark was implying that @csnover wishes that the QUnit team would halt new development efforts on QUnit and then dedicate that time to working on Intern instead.

Sound about right, @csnover? If not, please correct me.

[JamesMGreene]

P.S. I'm semi-familiar with Intern.

[csnover]

@JamesMGreene Yes, that captures the gist of it. I know it’s a long shot, but architecturally we’re pretty solid (and will be even moreso after the current sprint is over) and provide a really good baseline that—and I think the QUnit interface demonstrates this reasonably well—is really robust and flexible. So instead of having to do redundant work on things like #364 or #405 or #543 or #590, which all are features Intern already has, I’d really like to be able to work together to focus on building/integrating more useful & unique features and things that will be more generally useful to the wider Web development community. Things like:

• Working with the WebDriver standards group to finalise a standard and encourage adoption
• Working with groups like Mozilla’s Marrionette team to get every browser exposing a native WebDriver endpoint for testing so things like this stop happening
• Integrate benchmarking
• Integrate mocks/stubs
• Integrate visual differencing tests
• Add other execution modes
• Add more extension points for the built-in Web server (reverse-proxying, middleware, etc.)
• Better documentation
• etc.

I think that writing QUnit tests for Intern would still require that test authors are using Intern's AMD configuration (or generating such wrappings).

Intern does use AMD as its module system because it Just Works in browsers with no extra steps, but if you were adamant about exposing globals for your tests instead, or automatically wrapping them, or using ES6 modules that can be transpiled, or whatever, it is definitely possible to do so.

[jzaefferer]

For anyone interested, a kind of status update:

• PR to add QUnit interface to Intern
• Branch for Globalize to use Intern with the QUnit interface

Both of these are being worked on by one of our GSoC students, who will later work on using Intern with jQuery Mobile.

[jzaefferer]

The migration from QUnit to Intern doesn't affect QUnit itself, and we're not abandoning QUnit anytime soon. So I'm closing this, since I don't think this ticket provides any value.

[csnover]

we're not abandoning QUnit anytime soon.

Why not? Seems like a lot of wasted effort to duplicate features instead of working together :(

[JamesMGreene]

I think @csnover's question is a more interesting one now given the impending changes to the Foundation.

[csnover]

If nothing else it would be useful to me if you could explain why you think there is no value in collaborating and/or why you do not want to do so.

[leobalter]

Collaborative work is always great, but abandoning QUnit is not my option right now. It's old but still works great. I like QUnit being simple and not trying to ship tons of extras as we already find some you already mentioned here Intern does.

There is a lot of things I would love to have more available time and more contributors to make QUnit better, that does not mean I'm abandoning the project. The team was able to land QUnit 1.19 and 1.20 in less than 2 months, and my plans are to keep publishing new versions faster, with good and documented features. I don't mind if we have to do it step by step.

QUnit is not dead. Far from it, it's being well used on lots of great projects, not only jQuery Core, jQuery UI, or jQuery Mobile. I can mention LoDash, Backbone, EmberJS, it is built in by default on ember-cli projects. You can find a lot of other projects using it, including small ones as QUnit is very easy to use on browsers, straight out of the box. They are all worth the available time I dedicate to work here.

Instead of dropping QUnit, I would suggest we could have more shared collaboration, as you might find projects like https://github.com/js-reporters/js-reporters where it any help would be awesome.

We can always work together, but sometimes we may not need to work on the same project.

[csnover]

Sorry, I still don’t understand but would like to understand why it is your feeling that it is better to continue to maintain/develop QUnit instead of working on unifying a code base. I will try to ask some specific things so I can maybe explain my confusion so you can tell me more about where you are coming from:

I like QUnit being simple and not trying to ship tons of extras as we already find some you already mentioned here Intern does. […] my plans are to keep publishing new versions faster, with good and documented features.

Can you tell me how the new features you plan to add to QUnit are differentiated from the “tons of extras” that Intern provides to test authors? Can you tell me which features Intern provides that you feel are excessive that you don’t like and are happy QUnit doesn’t have?

You can find a lot of other projects using it, including small ones as QUnit is very easy to use on browsers, straight out of the box.

As far as I know from my experience Intern is also easy to use in browsers out of the box, load client.html?config=tests/intern and it works. Are you saying it is harder to use in a browser because you have to write a configuration file instead of just getting global APIs? Is there something else that makes it more difficult than necessary that makes you not like it? Is there something that could be changed so that you do?

They are all worth the available time I dedicate to work here.

Since these projects would all have a solid migration path to Intern via the QUnit API of Intern, wouldn’t it be more worthwhile to dedicate time to brand new features and enhancements that aren’t in any test tool by working together on one code base? If not, maybe you can explain more why you think this is not so?

Frankly I would drop Intern at this point if it was less robust than QUnit, since I can’t continue to maintain it as the only developer that ever spends any time working on it. But as it is, it’s the more complete of the two, which is the only reason why I suggest it makes more sense to work on that code than this code. Are there any changes that could be made to Intern to make you want to help develop one code base together instead?