-
Notifications
You must be signed in to change notification settings - Fork 20.5k
Tests: Add simple tests for Android 2.3 #2509
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
Conversation
|
Anything that goes through only |
Most currently do. The fact that But yeah, I'm still not terribly convinced.
Pulling such tests to a separate module would be catering to Android 2.3 too much, IMO; we'd break module separation just because of one browser. IMO it's easier (& better) to just skip problematic tests as we started to do now. The problem is not only failing tests, though. Those tests run extremely slow, usually ~1/3 of the modules time out and I have to restart those runs a few times before they stabilize and (mostly) pass to be sure we didn't regress. That's quite tedious. Running just very basic tests should at least help with this problem. |
test/unit/basic.js
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This already looks like too much... I'd expect to see one test per module (as you have), but no more than 10 assertions per test, and hopefully even fewer. For the CSS module, maybe one assertion like assert.equal( div.css( "width", "50px" ).css( "width" ), "50px", ".css getter/setter" ) and one for .show/.hide and call it done.
7a36083 to
8d090d4
Compare
|
PR updated (traversing & wrap tests to be written). |
|
Ready for final review. |
|
Now I'm really wanting to get some code coverage stats. :) |
test/unit/basic.js
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you update these to use assert.async instead of stop/start?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do this across the all unit files, so it could be done later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, since I use the new syntax in these files I may as well get it right.
I had significant problems with getting coverage to be generated in our current setup (most likely I did everything wrong :D), in the end I hacked it around in PhantomJS but excluding
|
|
These stats for all modules? Could run just |
|
No, just for |
|
Travis fails because of problems with installing old jsdom... Can we get #2526 landed ASAP? EDIT: restarting the job helped. But that's yet another reason that it's not worth automating testing on old jsdom, too much trouble for too little gain. |
|
This looks nice. 👍 |
|
👍 |
test/unit/basic.js
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need to do the tracking yourself; just use assert.async multiple times (cf. test/unit/deferred.js).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated, although that doesn't save that much. Ideally assert.async() would accept a parameter indicating how many async operations are expected and that would require calling done() this many times.
BTW, done.pop().call() is not needed, it's just done.pop()() after all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course you're right about .call(), and I agree on the former point. In fact, I meant to create a ticket for that earlier, but it fell off my radar. Anyway, corrected now: qunitjs/qunit/issues/843
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for creating a ticket, I should've done it myself. :)
Commit 2c7e9c9 added the basic test suite; these are the only tests that are now run on Android 2.3 on master. On compat we're keeping full Android 2.3 support for now but the tests and the testswarm basic run mode have been cherry-picked anyway to reduce the divergence between branches. (cherry-picked from 2c7e9c9) Fixes gh-2505 Closes gh-2509 Refs gh-2483
Fixes gh-2505
Refs gh-2483
@jquery/core This is an initial stab at simple tests for Android 2.3 but please review what I have before I write tests for other modules.
I've created a separate "module" called
basicto contain those selected tests; I also added it to the list run by regular browsers so that we immediately know if those tests are ok.Note that tests are very basic but testing the whole API even without edge cases (however you define them) would be way too much; if we run more than 10% of assertions in Android 2.3 it will be unstable (older browsers fare better with many modules with few tests in them rather than one module with all). I'd rather remove some CSS tests from this list than add more.
I've temporarily modified our Jenkins jobs to see how that would look:
Even these 18 CSS tests seem to sometimes run very slow on Android 2.3: they were running for 11 minutes & timed out, after restarting they passed almost immediately...