I’ve learned many tips and tricks from the Ember.js Community slack that have been lost to other users over the years. I know firsthand how valuable knowing the right trick here or there is to unblocking your problem. So let’s hear them!
Criteria and Guidelines:
It should be generic, though posting specifics to QUnit or Mocha seem fine.
It should be small and understandable.
It should provide sufficient detail to help others use and implement it.
Even small things can help people, so don’t think you can’t share because it is “too basic” or “everybody knows that,” because someone out there might not and this could help them.
And a little bit of attribution goes a long way. If you found this out from someone in the Slack channel, give them a shout out.
You’re experience is valuable, so please feel free to share!
I think it fair that I start.
Get Settled State
Ember’s test harness wants to wait for async behavior to be completed before it advances the test. It does so by returning a wait promise from many of the test helpers (e.g. visit). The wait function is covered very well in this blogpost. To simplify the wait helper returns a promise that resolves when the following things have completed:
scheduled run loops
And there is a neat way to kinda “cheat” to figure that out.
Take for instance you have a visit('/some-route'), which does return a wait promise, and you debugger; immediately afterward. You can call the following to get easy access to the state of the wait:
Just wanted to mention that the @ember/test-helpersAPI documentation says this about getSettledState:
Check various settledness metrics, and return an object with the following properties:
hasRunLoop - Checks if a run-loop has been started. If it has, this will
be true otherwise it will be false.
hasPendingTimers - Checks if there are scheduled timers in the run-loop.
These pending timers are primarily registered by Ember.run.schedule. If
there are pending timers, this will be true, otherwise false.
hasPendingWaiters - Checks if any registered test waiters are still
pending (e.g. the waiter returns true). If there are pending waiters,
this will be true, otherwise false.
hasPendingRequests - Checks if there are pending AJAX requests (based on
ajaxSend / ajaxComplete events triggered by jQuery.ajax). If there
are pending requests, this will be true, otherwise false.
pendingRequestCount - The count of pending AJAX requests.
From my experience working in a larger application, I find narrowing in on a single test or suite indispensible. I run something like ember test --filter 'my test name' --launch nothing. Why --launch nothing? I prefer opening the test server suite in my already open browser instead of ember-cli spawning a new browser for me. This starts the testing server so you can simply navigate to the testing URL. (probably localhost:7357)
3rd party library imports
If you import 3rd party libraries using app.import in your ember-cli-build.js, it can be useful to include development sources instead of the already minified assets. For example, say you are using the Highchart’s library. In your application’s ember-cli-build.js, you can include it like so:
This is great! I love the ember test --filter --no-launch command. In fact I have an alias that places the filter at the end like: alias etsf='ember test --no-launch --filter= ' which let’s you invoke it with etsf jonathan.
FYI, I’ve heard @rwjblue say on multiple occasions that minified assets should never be imported this way, even into the production, because ember-cli will try to re-minify them, which can cause issues. Ideally there would be an option within the import call to say “skip minification”, but I don’t think that exists yet.
Huh, I did not know that. This sounds like a perfect opportunity to clarify and document the appropriate way to import assets on the primary ember-cli website. Could you try opening a PR with this information @Panman8201?