Add MDN examples to tests.

[onlywei]

This helps ensure that passing in a URL object instead of a string to the 2nd argument of the constructor works as expected.

Related issue: whatwg/url#80

[onlywei]

@domenic It looks like on master, the behavior is already OK. I added some explicit tests to ensure this.

@mightyguava I'm not sure why your situation isn't working.

[Sebmaster]

Can you rebase on master? Apparently jshint broke the config file in a non-major...

[onlywei]

@Sebmaster ah, I was just fixing the .jshintrc myself locally. I'll rebase.

[onlywei]

@Sebmaster @domenic I just did a little more investigation into why @mightyguava is experiencing errors. It looks like the "built" lib/url.js file that we get when we npm install whatwg-url-compat does NOT pass these tests. These tests are not run against that file, and I DO get the error like this:

var URL = require('whatwg-url-compat').createURLConstructor();

var b = new URL("https://developer.mozilla.org");
var c = new URL("en-US/docs", b);

This code snippet will throw the error:

node_modules/whatwg-url-compat/lib/url.js:455
  return url.replace(/^[\u0000-\u001F\u0020]+|[\u0000-\u001F\u0020]+$/g, "");
             ^

TypeError: url.replace is not a function
    at trimControlChars (/Users/wei/development/urbancompass/src/js/node_modules/whatwg-url-compat/lib/url.js:455:14)
    at new URLStateMachine (/Users/wei/development/urbancompass/src/js/node_modules/whatwg-url-compat/lib/url.js:480:18)
    at URL.init (/Users/wei/development/urbancompass/src/js/node_modules/whatwg-url-compat/lib/url.js:1324:18)
    at new URL (/Users/wei/development/urbancompass/src/js/node_modules/whatwg-url-compat/lib/url.js:1344:10)
    at Object.<anonymous> (/Users/wei/development/urbancompass/src/js/url-test.js:6:9)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Function.Module.runMain (module.js:467:10)

Opening an issue also about this, I don't think I can fix this on my own.

[Sebmaster]

The packages on npm haven't been updated to the new rework yet since I'll still have to review the url PR on jsdom to see how they interface with each other.

The tests are executed against the built file (the source file actually contains an undefined function, so wouldn't actually work).

[domenic]

please get rid of these "a", "b", ... "j" strings.

[onlywei]

May I ask why? They correspond to the MDN examples and help determine which of the assert statements are actually failing. Without them, it would be difficult to see since many of the expected strings are identical.

[domenic]

They don't help me as a developer at all. They cause the assertion message to be "a" instead of "asdfasdf did not strict equal https://developer.mozilla.org/"

[domenic]

I can tell which assert is failing from the line number.

[onlywei]

Sounds good. I'll remove them.

[domenic]

This comment is incorrect (maybe MDN is incorrect). It should be a TypeError.

[onlywei]

It's possible that MDN is incorrect. I'll just remove the comment.

[onlywei]

Hmm, npm run build and npm test and npm lint all seem to pass locally, not sure why Travis is failing.

[onlywei]

Hmm, Travis seems to have been stuck on nvm install stable at 4.8% for the past 2 hours.

[Sebmaster]

Yeah, seems like it has a bit of a problem, I'll get to reviewing all changes tomorrow at the earliest anyways though so maybe it'll be fixed by then.