Should jQuery UI's test harness be independent of MAMP

"independent, lightweight web framework" is kind of meaningless. What are these independent of? We're certainly not going to make ruby a dependency for running tests.

We don't have a dependency on MAMP. We have a dependency on PHP (for very few things), and any web server.

What I can say is this: If I download ember source, to run the test suite all I need to do is bundle && rackup, browse to a URL, and violà, I'm able to run the tests to see if my contributions work.

My proposition is that jQuery UI's barriers to contribution would lower if one doesn't have to go and grab an installer (*amp series) or learn mongoose or read about setting up a LAMP stack. While adding this capability I'm imagining need not preclude the capability of using MAMP/WAMP/WTFAMP, to have the server launch-able from the CLI, ready-to-go, without having to wrangle with yet another configuration together seems valuable.

What I can say is this: If I download ember source, to run the test suite all I need to do is:

• Install rvm
• Install ruby 1.9.2
• Install bundler
• Run bundle
• Run rackup
• Finally open my browser

It's amazing how much simpler and seemingly more lightweight their process is when you already use ruby, isn't it?

Would be nice though if we built a node webserver into grunt and remove PHP as a dep altogether. Food for thought.

I realize some people on the team want to get down to just node as a dependency, but I still really hate the idea of having to start a web server all the time. Also, are we going to start running node servers for demos? Keep in mind that jquery-ui demos and jqueryui.com demos are the same files (at least for now).

Oh, I wasn't considering that angle, Scott. From a pure dependency standpoint, going with Node only would be awesome, but the practicality of PHP for our demos makes sense. Consider my suggestion invalid.

I'm glad this is getting some further consideration.

As I said in my original post, there will be legitimate differences on which technology to use. Those are implementation discussions. By explicitly declaiming that that was under consideration ("why use a Ruby versus / Python- / NodeJS- etc.") I hoped to keep the discussion, at least preliminarily, focused on the feature per se. A Ruby toolchain is not without its headaches, nor is an NPM-based toolchain.

What's more generally the case is this: that in several Javascript frameworks one can do $PROGRAM $COMMAND and violà: a test server is up and running. The test harness ships with the library. This seems like a good thing. Should work be put toward making that happen or is it impossible or is there no desire? I'm in the "for" column. That's all this request is after.

Example:

➜  $PROGRAM $COMMAND
[2012-12-13 08:51:22] INFO  JqueryUI Test Server
[2012-12-13 08:51:22] INFO  Some Programming Language Version blah
[2012-12-13 08:51:22] INFO  WEBrick::HTTPServer#start: pid=37910 port=9292
[2012-12-13 08:51:22] Jquery UI Test Framework is up and running: visit http://localhost:8066
( optional browser launch to that URL )

The portability of the code to *also* be the web site is a really nice feature and I wouldn't want to see that get broken, but again, for this request, that's not point I'm attempting to put forward for consideration.

This feature is something I personally hate. But, for what it's worth, the only options that can even be discussed must be either PHP or node.js. We will not allow a ruby/python/anything-else dependency.

Would be nice if we could add something as suggested, without breaking what we already use. Addding an option, instead of replacing the existing one. Again depends on the PHP dependency, and what we can do with that.

Jörn,

Can you or Scott detail what the nature of the PHP dependency is? I think offering a test harness that comes along with the git clone will make jQueryUI something that more people can get involved with.

There's actually very little. If you look for php files inside the repo, there's one to mock a autocomplete remote source (demos/autocomplete/search.php) and two files in demos/tabs to simulate slow and broken responses for ajax panels. So to run unit tests, you can just run

python -m SimpleHTTPServer

I think we might be able to amend our set up instructions to say something like: "in order to test the demos, you'll need a PHP webserver like MAMP, but in order to run the test suite, all you need to do is run grunt watch and then point your browser to...".

Does that work?

First: I see that this ticket is closed / wontfix. Since we're discussing it, I think it would be best to have it open and unresolved. Others may have valuable input here, but they won't see the ticket since it's in the closed bucket.

Second: Yes, Jörn and Mike, you are both providing ideas well aligned to the spirit of what I was hoping for. Jörn, the SimpleHTTPServer provides the function and Mike, your suggestion syntax is exactly what I was hoping for to launch that SimpleHTTPServer-like server. I might suggest that a task name like grunt testserver would help communicate that the type of server is explicitly one for running tests, but that's just a nit.

Presently, attempting grunt watch says it's missing some configuration information. I've not yet learned enough about Grunt to have tried to hack that solution together, though. And I have a day of work before I can get to it. But if your two recommendations can be united I think you'd be delivering a valuable tool.

To come full circle, at such a time as that I'd be glad to see this item as closed / resolved :-D

FWIW, I don't really want to deviate from core, and core has a lot of ajax requests. I'd rather you file a ticket against jQuery and get a response there.