Acceptance tests halt due to run.later scheduling about ember-cli-flash HOT 6 CLOSED

I've run into the same issue when trying to test the mouseover-ed feature.
I think what could be done is to overload the _destroyLater method instead of removing it.
Then we could for instance do something like this:

if the test should lead to _destroyLater being call:

FlashObject.reopen({_destroyLater: function () { ok(true, 'yes it was called!'); });

or ok(false) if the method shouldn't be called.

that being said... I haven't had time to try coding it since I thought about it and maybe it is a rubbish idea 😄

from ember-cli-flash.

A declarative public API for testing would be lovely.

This isn’t a serious suggestion, but food for thought:

test('say hello', function(assert) {
  visit('/');
  click('button:contains("Say hello"));
  pauseFlashes();
  andThen(() => { assert.equal(find(':contains("Hiya")').length, 1); });
  flushFlashes();
  andThen(() => { assert.equal(find(':contains("Hiya")').length, 0); });
});

from ember-cli-flash.

Thanks for reporting this @jgwhite and @leojpod! Yeah, it is definitely a problem I want to fix. I like the idea of being able to pause / flush flashes in testing, but I think I'd prefer for the flashes to just work in testing (without additional helpers) in a way that you'd expect. I'll investigate over the next few days to figure out the best approach.

from ember-cli-flash.

Here is another idea. I have ENV.stickyFlash = false set in environment.js (or some subset of flashMessageDefaults as explained in the README) then add messages with something like:

Ember.get(this, 'flashMessages').add({
  message: 'Custom message',
  sticky: ENV.stickyFlash
});

This just explicitly sets sticky to the already default false. Now in my test I have ENV.stickyFlash = true so the message is still present inside any andThen

from ember-cli-flash.

Using Mocha, the run.later for non-sticky flashes causes the _destroyLater hook to run immediately, which causes the tests asserting the existence of a flash to fail, but it's basically the same issue.

From my perspective, the most intuitive approach is to treat flashes as always sticky in test. That's because I almost always want to assert that they were shown, but I have complete faith that if I told ember-cli-flash that they should go away after five seconds, then they will. In the rare instances where you need to make assertions against a clean slate within the same test case, you could provide a clearFlashMessages helper.

Based on that, I think @jgwhite's workaround is the simplest, least surprising option, and I'd consider making it automatic. That way you spend basically zero mental overhead thinking about how your flashes might work differently in test than in development and production.

from ember-cli-flash.

Yeah, that's a good point @cowboyd, I like that approach and I'm gonna work on implementing that and the helper.

@JarrodCTaylor you can also set sticky: true inside of your dummy app's config/environment

from ember-cli-flash.