Gathering detailed insights and metrics for ember-native-dom-helpers
Gathering detailed insights and metrics for ember-native-dom-helpers
Test helpers for your integration tests that fire native events
npm install ember-native-dom-helpers
Typescript
Module System
Min. Node Version
Node Version
NPM Version
67.3
Supply Chain
87
Quality
72.6
Maintenance
25
Vulnerability
95.6
License
JavaScript (96.1%)
Handlebars (2%)
HTML (1.85%)
CSS (0.04%)
Love this project? Help keep it running — sponsor us today! 🚀
Total Downloads
16,522,925
Last Day
1,862
Last Week
9,582
Last Month
39,888
Last Year
883,228
MIT License
186 Stars
242 Commits
37 Forks
10 Watchers
25 Branches
22 Contributors
Updated on May 30, 2024
Minified
Minified + Gzipped
Latest Version
0.7.0
Package Id
ember-native-dom-helpers@0.7.0
Size
12.42 kB
NPM Version
6.14.4
Node Version
13.12.0
Published on
Jan 23, 2021
Cumulative downloads
Total Downloads
Last Day
15.9%
1,862
Compared to previous day
Last Week
20.7%
9,582
Compared to previous week
Last Month
-6%
39,888
Compared to previous month
Last Year
-41.5%
883,228
Compared to previous year
2
22
In Ember, since ember-(cli-)qunit
3.X (around late 2017) there is a new testing API that already
provides almost identical test helpers from the ones in this addon.
This addon was used as an experiment that helped bikeshed the API of the helpers that are now part
of default testing API, like click
, tap
, fillIn
and others.
The only two helpers in this addon that are not part of the default set of helpers that ship with Ember's
test harness are scrollTo(selectorOrHTMLElement, x, y)
and selectFiles(selectorOrHTMLElement, files = [])
.
Unless you want to use those, you are better served using the helpers provided by @ember/test-helpers
.
Test helpers for integration tests that mimic the behaviour of the acceptance test helpers provided by Ember.
Use this addon as a way to start the gradual migration towards the future "testing unification" RFC, which proposes only native DOM.
See the Grand Testing Unification RFC
Status: (Pre) 1.0, although we have a good idea about what the needs are for test helpers, we are working through a few points on what changes are needed when using only standard DOM APIs (i.e. without jQuery).
1import { click, fillIn, find, findAll, keyEvent, triggerEvent } from 'ember-native-dom-helpers'; 2 3moduleForComponent('my-component', 'Integration | Component | my-component', { 4 integration: true 5}); 6 7 8test('I can interact with my component', async function(assert) { 9 this.render(hbs``` 10 {{my-component}} 11 ```); 12 13 await fillIn('.some-input', 'some text'); 14 await click('.main-button'); 15 await keyEvent('.other-input', 'keyup', 40); // down arrow 16 await triggerEvent('.some-drop-area', 'mouseenter'); 17 18 assert.ok(find('.result-of-event-happened')); 19 assert.equal(findAll('.result-list-item').length, 3); 20})
You can use the exact same helpers for your acceptance tests. All interaction helpers like
click
, fillIn
, et al., return a promise that fullfils when "the world has settled"
(that is, there are no pending requests or promises, and the runloop has been drained), which
is what the andThen
acceptance helper used to do. However, this helper can now be replaced
by the async
/await
syntax in ES2017, yielding easier-to-read tests:
1import { visit, click, find, fillIn } from 'ember-native-dom-helpers'; 2 3moduleForAcceptance('Acceptance | Sign up'); 4 5test('Usage awaiting the world to settle', async function(assert) { 6 await visit('/sign-up'); 7 8 await fillIn('.first-name', 'Chuck'); 9 await fillIn('.last-name', 'Berry'); 10 await click('.submit-btn'); 11 12 assert.ok(find('.welcome-msg'), 'There is a welcome banner'); 13 assert.equal(find('.welcome-msg-name'), 'Chuck'); 14});
this.$(selector).click()
The main advantages are:
Fires native events: In Ember, when adding events with the onclick={{action "foo"}}
syntax,
dispatching jQuery events leads to the action being called twice. Additionally, there are subtle
differences between jQuery and Native events that can bite you. Firing native events fixes that
problem, but they are very verbose and there are browser incompatibilities. This addon makes
firing native events a no-brainer.
Runloop aware: These helpers automatically spawn a runloop, so you don't need to wrap
every interaction with Ember.run(() => /* interact with element */ );
.
wait
by default: All the helpers return the wait()
promise, making it possible to
wait for asynchronous side-effects with async/await
. (Note that for using async/await
in browsers without native support you must install ember-maybe-import-regenerator).
1test('some test', async function(assert) { 2 this.render(hbs```{{my-component}}```); 3 4 await click('.my-button'); 5 6 assert.ok('something happened'); 7});
More realistic behaviour: When a user clicks on an element, click
is not the only event fired.
In a real click, the sequence of events is mousedown
, focus
, mouseup
, click
. When a user
fills in an input the sequence of events is focus
, <mutate-value>
, input
, and change
.
The helpers provided by this addon fire those events in the right order, simulating more
closely how a real user would interact with the page.
find
/findAll
helpersfind
helper uses document.querySelector
and will return a single HTMLElement
or null
.findAll
helper uses document.querySelectorAll
and returns an Array
with zero or more elements.find
and findAll
helpers query the DOM within #ember-testing
.config/environment.js
settings, add to tests/test-helper.js
…1import { settings } from 'ember-native-dom-helpers'; 2import config from '../config/environment'; 3const { APP: { rootElement } } = config; 4 5settings.rootElement = rootElement || settings.rootElement;
Fear not. If you prefer to use jQuery, just wrap the result and do your thing:
1assert.equal($(find('.my-class')).attr('aria-owns'), '#id123')
There is one new helper in this addon that enables some testing patterns that weren't previously easy to perform using traditional methods.
Since the andThen
helper waits for the app to settle (no pending requests or promises),
and every integration test interaction is wrapped in Ember.run
, there is no easy way
to test transient state, like loading substates or the state of a component, while some
promise is pending, without an awkward setup of timeouts.
Now, however, thanks to explicit usage of promises and the waitUntil
helper, you can
perform assertions on unsettled states:
1import { visit, click, find, fillIn, waitUntil, currentURL } from 'ember-native-dom-helpers'; 2 3moduleForAcceptance('Acceptance | Sign up'); 4 5test('Usage awaiting the world to settle', async function(assert) { 6 await visit('/login'); 7 8 await fillIn('.email', '007@gov.uk'); 9 await fillIn('.password', 'goldeneye'); 10 let promise = click('.submit-btn'); 11 12 // We wait until the loading substate, that takes 200ms to appear, is displayed 13 await waitUntil(() => find('.substate-spinner')); 14 assert.equal(find('.loading-substate-header').textContent.trim(), 'Loading mission. Please wait, Mr. Bond'); 15 16 await promise; // now we wait until the dashboard is fully loaded 17 assert.equal(currentURL(), '/dashboard'); 18 assert.equal(find('.section-header').textContent, 'Main dashboard'); 19});
Yes, there is a codemod that will help you transform your test suite to this new style "automatically". Check https://github.com/simonihmig/ember-native-dom-helpers-codemod.
The codemod can't make a perfect conversion, but it will do most of the work for you.
click(selectorOrHTMLElement, contextHTMLElement, eventOptions)
tap(selectorOrHTMLElement, eventOptions)
fillIn(selectorOrHTMLElement, text)
find(selector, contextHTMLElement)
(query for an element in test DOM, #ember-testing
)findAll(selector, contextHTMLElement)
(query for elements in test DOM, #ember-testing
)findWithAssert(selector, contextHTMLElement)
(same as find
, but raises an Error if no result)keyEvent(selectorOrHTMLElement, type, keyCode, modifiers)
(type being keydown
, keyup
or keypress
, modifiers being object with { ctrlKey: false, altKey: false, shiftKey: false, metaKey: false }
)triggerEvent(selectorOrHTMLElement, type, options)
focus(selectorOrHTMLElement)
blur(selectorOrHTMLElement)
scrollTo(selectorOrHTMLElement, x, y)
selectFiles(selectorOrHTMLElement, files = [])
(selects the file(s)/Blob(s) to the given input[type=file]
. Examplevisit(url)
(only available in acceptance. Raises an error in integration.)waitUntil(function, options)
(Polls the page until the given callback returns a truthy value, or timesout after 1s)waitFor(selector, options)
(Convenience for the most common use-case of waitUntil
. It polls the page until the element with the given selector is on the page, or timesout after 1s. It accepts a count: 3
option to await a specific number of matches.)currentURL()
Identical to the one provided by Ember.currentPath()
Identical to the one provided by Ember.currentRouteName()
Identical to the one provided by Ember.tap
In order for tap
to work, your browser has to support touch events. Desktop Chrome and Firefox
have touch events disabled unless the device emulation mode is on. To enable touch events in your
CI, you need to configure testem like the testem.js
file on this repo.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 13/30 approved changesets -- score normalized to 4
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
133 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-02-10
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More