Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests: Replace resource loader with AMD #1335

Closed
wants to merge 20 commits into from
Closed

Tests: Replace resource loader with AMD #1335

wants to merge 20 commits into from

Conversation

rxaviers
Copy link
Member

@rxaviers rxaviers commented Sep 2, 2014

💥 WIP...

Pulll request's goal is to AMDify tests for 1.12.0 release and address part of http://bugs.jqueryui.com/ticket/10119.

TODO:

@rxaviers
Copy link
Member Author

rxaviers commented Sep 2, 2014

Initial PR based on #1029

//registered for it. Start with most specific name
//and work up from it.
for (i = syms.length; i > 0; i -= 1) {
parentModule = sy
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to use bower + bower_copy to place this file.

@rxaviers
Copy link
Member Author

rxaviers commented Sep 2, 2014

Better suggestions for the commit message? Actual: "Tests: Replace resource loader with AMD"

"ui": "../../../ui"
},
shim: {
"jquery.simulate": [ "jquery" ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What did we ever decide for jquery-color as far as UMD goes? The same would apply here to jquery-simulate. /cc @gnarf

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just follow what UI has, unless you think it's reasonable to use in node.

@mikesherov
Copy link
Member

Don't indent inside the define please. Creates an unnecessarily high number of changes, and is against the style guide: http://contribute.jquery.org/style-guide/js/#full-file-closures

@rxaviers
Copy link
Member Author

rxaviers commented Sep 2, 2014

Don't indent inside the define please...

Absolutely... Fixed.

"qunit/MIT-LICENSE.txt": "qunit/MIT-LICENSE.txt",
"qunit/qunit.css": "qunit/qunit/qunit.css",
"qunit/qunit.js": "qunit/qunit/qunit.js",
"requirejs/require.js": "requirejs/require.js",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

requirejs should be visually split from qunit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any preference on how to order it between qunits and jqueries? They are not in sort order... Should I use dependencies sort order, than jqueries? Whatever order is fine?

@mikesherov
Copy link
Member

Still looks like a huge number of changes. Please squash the commits so that there aren't entries in the history having them changed and changed back.

@rxaviers
Copy link
Member Author

rxaviers commented Sep 2, 2014

All fix commits are going to be squashed before merged, not now to save history in this PR though.

@@ -134,6 +116,29 @@ <h3 class="bar">Rent one bear, ...</h3>
</dd>
</dl>

<script src="../../../external/requirejs/require.js"></script>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did all of this move down? It's not even the end of the body, it's in the fixture.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was supposed to be in the end of the body, not in the fixture div (needs fix). Anyway, the reason for moving it down was to favor rendering of other elements of the page before loading and executing these scripts.

<script src="../helper/jquery.js"></script>
<script>
QUnit.config.autostart = false;
require.config({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume we'd have the config defined somewhere else for re-use.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeap, this will eventually get wrapped into a helper or something.

@rxaviers rxaviers force-pushed the AMDify-tests branch 2 times, most recently from a113a9e to fc133d5 Compare September 3, 2014 14:05
@mikesherov
Copy link
Member

The next Qunit will no longer rely on test loading order for rerun functionality. We should wait till that lands and then re-revert the changes so we don't have to wrap all tests in an a fucntion to be executed later.

@jzaefferer
Copy link
Member

I just tried to test this, by checking out the PR and opening tests/unit/accordion/accordion.html. It gets stuck on "Running...", with this exception on the console:

...

Regarding execution order, the require.js docs say this:

RequireJS waits for all dependencies to load, figures out the right order in which to call the functions that define the modules, then calls the module definition functions in the right order.

So it shouldn't matter in what order the file content is loaded, in the end they're executed "in the right order". Since it doesn't define the semantics of "right order", this may not be what we're looking for. Since the current setup in this PR is broken, I can't really verify it here.

@jzaefferer
Copy link
Member

I rebased this branch against master and fixed the failure (switching two lines, not sure how that happened).

I've investigated if there's some way to load modules in the specified order without extra workarounds. The order only depends on other dependencies, but loading several files that have to dependencies to each other results in seemingly random order. Its actually not random, as far as I can tell its in the specified order, except when one of the modules loads a dependency not needed by the others, so here "accordion_core" is executed last, since it also loads "jquery-simulate".

Anyway, one alternative to what @rxaviers implemented so far is nesting require calls like this:

require(["./accordion_common"], function() {
    require(["./accordion_core"], function() {
        require(["./accordion_events"], function() {
            require(["./accordion_methods"], function() {
                require(["./accordion_options"], function() {
                    QUnit.start();
                })
            })
        })
    })
});

I'm hoping there's a better way.

The above at least requires less modifications of our test files (no need for the separate wrapper) and could probably be abstracted so that we can still do this:

requireTests([
    "./accordion_common",
    "./accordion_core",
    "./accordion_events" ,
    "./accordion_methods",
    "./accordion_options"
], function() {
    QUnit.start();
});

@rxaviers
Copy link
Member Author

Updates:

  • Moved common require.config to a helper. It allows simplification (see 337b775) of each tests/unit/<component>/<component>.html.
  • Wrapped "using nested requires" into require_series, so it's saner using it.
  • By using nested requires, we avoid the extra indentation on tests/unit/<component>/<component>_<test_module>.js files and we get a better (more concise) diff (example).

@rxaviers
Copy link
Member Author

Update, I'm in the process of updating the tests of all other components. The problem I'm facing is that I get intermittent failures running datepicker tests tests/unit/datepicker/datepicker.html...

onFocus();
};

element.bind( "focus", fn )[ 0 ].focus();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious. Should we replace [ 0 ] with .first()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@c43500 Please reply using GitHub; your email replies have no formatting.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rxaviers No. Doing that will likely break tests because you would be doing something different (triggering a focus event through jQuery instead of natively focusing the element).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Thanks

@rxaviers
Copy link
Member Author

Update. All tests are running. Some are failing (including the intermittent one described above). Need to:

  • Figure out why the remaining ones are failing and fix them.
  • Make sure swarminject is working.

@jzaefferer
Copy link
Member

To test swarminject: Log into Jenkins, create new job, pick some option to make it a copy of the existing jQuery UI (master) job, change branch from master to AMDify-tests, disable build triggers, save, then start a manual run.

@jzaefferer
Copy link
Member

Can we smash all the files in test/unit/helper/ into one js file? I don't see the point in splitting those up when we use them on every page. And you can get rid of the window.require dependency by exporting the right variable: http://requirejs.org/docs/api.html#config

var require = { ... };

Would also remove the need to export window.helper.jqueryUrl at all, since you could just use that directly.

One issue I noticed when running datepicker tests: The order isn't consistent. JSHint tests used to run first, now they run at some point later, whatever the logic for that. I guess the problem is the require call inside tests/unit/helper/testsuite.js, which then defines another test.

I also get many errors on every other run of the datepicker tests. There seems to be a problem with expect() calls, which probably means that QUnit's globals aren't available - expect() is always the first method called in each test.

Not sure yet what exactly is going on, hope that helps. Should have more time later.

@rxaviers
Copy link
Member Author

Sure, we can smash the helpers now that we know where each is used. Note helper/css.js is the only one needed in the header before style loading. I'd encourage having that one separate. (and I guess you meant window.helper instead)

I've updated the description with the remaining TODOs.

return;
}

require([ "jshint" ], function() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this require and instead have "jshint" under the test definition.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would load this when we don't need it. Just swap this with the line below.

Just swap this with the line below.
@jzaefferer jzaefferer added this to the land-before-esformatter milestone Mar 13, 2015
@jzaefferer jzaefferer deleted the AMDify-tests branch May 15, 2015 11:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants