Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#11265 closed bug (duplicate)

Unit tests failing.

Reported by: cowboy Owned by: Rick Waldron
Priority: low Milestone: None
Component: misc Version: 1.7.1
Keywords: Cc: mikesherov
Blocked by: Blocking:

Description

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.

Change History (10)

comment:1 Changed 7 years ago by Rick Waldron

Component: unfiledmisc
Owner: set to Rick Waldron
Status: newassigned

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

comment:2 Changed 7 years ago by dmethvin

Cc: mikesherov added

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.

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by timmywil

Priority: undecidedlow

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

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by 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.

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by 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.

comment:9 Changed 7 years ago by mikesherov

Resolution: duplicate
Status: assignedclosed

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.

comment:10 Changed 7 years ago by mikesherov

Duplicate of #10901.

Note: See TracTickets for help on using tickets.