mirror of
https://github.com/twbs/bootstrap.git
synced 2024-11-29 11:24:18 +01:00
5fd7bc1554
as role="menu" is a very specific (and strict) ARIA pattern for desktop-like application menus, and our dropdowns are often used as pure navigation dropdowns, this change abandons ARIA menus for a more open-ended and light-weight approach (see http://heydonworks.com/practical_aria_examples/#submenus and http://www.w3.org/WAI/tutorials/menus/flyout/#improve-screen-reader-support-using-wai-aria) note that in dropdown.js, switched to now target ``.dropdown-menu`` instead of ``role["menu"]`` - this also prevents bootstrap scripts from "bleeding" into non-bootstrap components on the same page. also removed the ``role=["listbox"]`` part, which appears to be vestigial/unused (only place in bootstrap that uses that role are carousels, and their key handling is done separately) |
||
---|---|---|
.. | ||
unit | ||
vendor | ||
visual | ||
index.html | ||
README.md |
How does Bootstrap's test suite work?
Bootstrap uses QUnit, a powerful, easy-to-use JavaScript unit test framework. Each plugin has a file dedicated to its tests in unit/<plugin-name>.js
.
unit/
contains the unit test files for each Bootstrap plugin.vendor/
contains third-party testing-related code (QUnit and jQuery).visual/
contains "visual" tests which are run interactively in real browsers and require manual verification by humans.
To run the unit test suite via PhantomJS, run grunt test-js
.
To run the unit test suite via a real web browser, open index.html
in the browser.
How do I add a new unit test?
- Locate and open the file dedicated to the plugin which you need to add tests to (
unit/<plugin-name>.js
). - Review the QUnit API Documentation and use the existing tests as references for how to structure your new tests.
- Write the necessary unit test(s) for the new or revised functionality.
- Run
grunt test-js
to see the results of your newly-added test(s).
Note: Your new unit tests should fail before your changes are applied to the plugin, and should pass after your changes are applied to the plugin.
What should a unit test look like?
- Each test should have a unique name clearly stating what unit is being tested.
- Each test should test only one unit per test, although one test can include several assertions. Create multiple tests for multiple units of functionality.
- Each test should begin with
assert.expect
to ensure that the expected assertions are run. - Each test should follow the project's JavaScript Code Guidelines
Example tests
// Synchronous test
QUnit.test('should describe the unit being tested', function (assert) {
assert.expect(1)
var templateHTML = '<div class="alert alert-danger fade in">'
+ '<a class="close" href="#" data-dismiss="alert">×</a>'
+ '<p><strong>Template necessary for the test.</p>'
+ '</div>'
var $alert = $(templateHTML).appendTo('#qunit-fixture').bootstrapAlert()
$alert.find('.close').click()
// Make assertion
assert.strictEqual($alert.hasClass('in'), false, 'remove .in class on .close click')
})
// Asynchronous test
QUnit.test('should describe the unit being tested', function (assert) {
assert.expect(1)
var done = assert.async()
$('<div title="tooltip title"></div>')
.appendTo('#qunit-fixture')
.on('shown.bs.tooltip', function () {
assert.ok(true, '"shown" event was fired after calling "show"')
done()
})
.bootstrapTooltip('show')
})