Unit tests failing.

[cowboy]

I just cloned the repo (at ​8e4859f), and test/index.html fails. Tons of 404 script errors when boxModelIE.html gets loaded.

FWIW, I'm serving static files using python -m SimpleHTTPServer which doesn't support PHP.

[Rick Waldron]

The non-php fallback is causing too many issues. We need to draw a line.

[dmethvin]

We get a lot of benefits from being able to use PHP, not sure we want to give that up. The resolution to this may be just to document our dependencies.

[mikesherov]

Agreed we need to draw a line...at some point we gotta say that PHP is a requirement.

None of the ajax unit tests run correctly without PHP. We resort to a hack that says just don't run those tests if the protocol is ​file://. But if you're using a non-PHP server and the ​http:// protocol, wouldn't the ajax tests fail too?

There are a few options here:

1. say PHP is a build req and make unit tests fail when run from ​file:// or PHP is disabled.
2. say node.js is a build req, convert all PHP to node.js, and make unit tests fail when run from file.
3. attempt to keep the non-PHP callback, but have it load build/jquery.js so we can have the unit tests always run against a single file, but this causes the tester to build after every change.

I'm all for #1.

[Timmy Willison]

Or, we could load scripts from a single file without php or node...right?

[Rick Waldron]

@dmethvin I'm not talking about removing PHP, I'm talking about making it a known requirement/dependency of the test suite.

@mikesherov I'm going to say #1 for now, but #2 is an ideal long term goal. I've been working with Ben to iron out grunt details and moving to one server dependency seems to make the most sense across the board

@timmywil, I think your missing some context here - this arises because we want to be able to test build unbuilt and built source.

[mikesherov]

this theoretically should work though. It's weird. I'm going to take a look at it.

Regarding the multiple files from one file, that's what the non-PHP fallback does. We run into issues though when the include_js.php is loaded asynchronously or in other edge cases. At one point or another, doing a bunch of document.write's inside a JS file exposes itself as such.

[Rick Waldron]

There were issues with the path of those document.write scripts, when running the core suite, so i fixed that, but now there are issues with the files that are loaded via iframe. The whole thing is a damn mess... but only if you dont have a PHP enabled server.

[mikesherov]

Wait, so, the document.writes all need to have an absolute path. I attempted to do that by inspecting the url and looking for "/test/" as the way to find what the "base" url is... can you describe what the url was when the tests were run so I can debug?

Before we just condemn non-PHP execution (even though I'm all for it), I'd like a chance at debugging this.

[mikesherov]

so, I already have a ticket about warning the user if they run tests without PHP. I'll just fix what was mentioned here in that ticket.

[mikesherov]

Duplicate of #10901.