Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#8904 closed feature (wontfix)

Should jQuery UI's test harness be independent of MAMP

Reported by: sgharms Owned by:
Priority: minor Milestone: 1.10.0
Component: ui.core Version: 1.9.2
Keywords: Cc:
Blocked by: Blocking:


Based on my work on EmberJS and other javascript frameworks I'm accustomed to having some sort of independent, lightweight web framework available for running the (Q)Unit tests. It seems a bit odd, to me at any rate, that the official advice, per the README, is to "install MAMP."

While MAMP is a fine product, supports a free version, and is steered by (I'm sure) lovely people, could we not use a simple Rack middleware built on free, lightweight components? While there may be a legitimate complaint around "why use a Ruby versus / Python- / NodeJS- etc." flavored solution, it seems that picking any one of these would be be lighter and more hackable solution compared to using MAMP.

Additionally I have some discomfort with the idea that JqueryUI is a gateway to MAMP's revenue stream (nice folks thought they may be).

Change History (14)

comment:1 Changed 10 years ago by Scott González

Resolution: wontfix
Status: newclosed

"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.

comment:2 Changed 10 years ago by sgharms

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.

comment:3 Changed 10 years ago by Scott González

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?

comment:4 Changed 10 years ago by mikesherov

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

comment:5 Changed 10 years ago by Scott González

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 demos are the same files (at least for now).

comment:6 Changed 10 years ago by mikesherov

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.

comment:7 Changed 10 years ago by sgharms

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.


[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.

comment:8 Changed 10 years ago by Scott González

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.

comment:9 Changed 10 years ago by Jörn Zaefferer

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.

comment:10 Changed 10 years ago by sgharms


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.

comment:11 Changed 10 years ago by Jörn Zaefferer

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 and then go to http://localhost:8000/tests/unit/index.html to run unit tests.

comment:12 Changed 10 years ago by mikesherov

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?

comment:13 Changed 10 years ago by sgharms

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

comment:14 Changed 10 years ago by Scott González

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.

Note: See TracTickets for help on using tickets.