Skip to main content

Search and Top Navigation

#8904 closed feature (wontfix)

Opened December 12, 2012 11:49PM UTC

Closed December 13, 2012 01:38AM UTC

Last modified December 14, 2012 05:58PM UTC

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:
Description

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

Attachments (0)
Change History (14)

Changed December 13, 2012 01:38AM UTC by scottgonzalez comment:1

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.

Changed December 13, 2012 02:04AM UTC by sgharms comment:2

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.

Changed December 13, 2012 03:05AM UTC by scottgonzalez comment:3

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?

Changed December 13, 2012 05:38AM UTC by mikesherov comment:4

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

Changed December 13, 2012 01:13PM UTC by scottgonzalez comment:5

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

Changed December 13, 2012 02:20PM UTC by mikesherov comment:6

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.

Changed December 13, 2012 05:04PM UTC by sgharms comment:7

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.

Changed December 13, 2012 05:14PM UTC by scottgonzalez comment:8

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.

Changed December 13, 2012 05:17PM UTC by jzaefferer comment:9

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.

Changed December 13, 2012 09:01PM UTC by sgharms comment:10

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.

Changed December 14, 2012 09:21AM UTC by jzaefferer comment:11

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.

Changed December 14, 2012 12:00PM UTC by mikesherov comment:12

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?

Changed December 14, 2012 05:27PM UTC by sgharms comment:13

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

Changed December 14, 2012 05:58PM UTC by scottgonzalez comment:14

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.