Skip to content
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

Acceptance Tests...again #88

Open
gte451f opened this issue Jul 20, 2016 · 6 comments
Open

Acceptance Tests...again #88

gte451f opened this issue Jul 20, 2016 · 6 comments

Comments

@gte451f
Copy link

gte451f commented Jul 20, 2016

I see that this has popped up here and there in previous issue but I am completely lost on how to verify success or failure on my tests.

Some examples seem to indicate you turn on alerts during testing but that slows things down:
// my-acceptence-test.js
import Notify from 'ember-notify';
Notify.testing = true;

I just want to detect if a notify.success() or notify.alert() is called from within the test. I've seen suggestions like "stub out notify.success" and to spy this.notify.alert() but I have no idea how to do that within a test.

Could someone give me a pointing to detect when success() or alert() is called from within an Acceptance test?

@plicjo
Copy link
Contributor

plicjo commented May 2, 2018

I'm struggling with this in 2018 too. I love this library, but this is backbreaking.

@plicjo
Copy link
Contributor

plicjo commented May 2, 2018

I'm able to acceptance test Ember Notify when it's configured to never close the alert.

I have a setting in my application controller that makes the alert never close in the test environment, but it works as normal in my production/development environment.

app/templates/application.hbs

{{outlet}}
{{ember-notify closeAfter=closeAfter}}

I then configure the library to not close in my application controller.

app/controllers/application.js

import Controller from '@ember/controller';
import config from '../config/environment';
import { computed } from '@ember/object';

export default Controller.extend({
  closeAfter: computed(function() {
    return config.environment == 'test' ? null : 5000;
  }),
});

And my acceptance tests are working fine!

@knownasilya
Copy link
Contributor

Is there a better alternative?

@knownasilya
Copy link
Contributor

Cc @rwjblue is there a standard or recommended way?

@NullVoxPopuli
Copy link

As a user of Bulma, and specifically, bulma-toast, and since I'm thinking about using this library instead of bulma-toast, and am also struggling with acceptance testing toasts... I'm very interested in the solution to this :)

@zofskeez
Copy link

I just ran into the same issue. Prior to Ember 3 we had been stubbing the notify service and while I was refactoring the acceptance tests I was seeing this.get('source').setTarget is not a function when registering the stub in the beforeEach hook.

The ember-notify component lives in our application template and we already had a computed prop setup to read the ENV from the config so conditionally rendering the ember-notify component fixed the issue.

{{#unless isTesting}}
  {{ember-notify closeAfter=3500}}
{{/unless}}

And the stub looks like...

export default Service.extend({
  lastMessage: null,

  alert(msg) {
    this.set('lastMessage', msg);
    console.log('Notify: '+msg);
  },
  info(msg) {
    this.set('lastMessage', msg);
    console.log('Notify: '+msg);
  },
  success(msg) {
    this.set('lastMessage', msg);
    console.log('Notify: '+msg);
  },
  warning(msg) {
    this.set('lastMessage', msg);
    console.log('Notify: '+msg);
  }
});

Register the stub...

import notifyStub from '/path-to-stub';
module('Application test name', function(hooks) {
  setupApplicationTest(hooks);
  hooks.beforeEach(function() {
    this.owner.register('service:notify', notifyStub);
  });
});

After that I can see the logs from the stub firing again and ember-notify is no longer throwing any errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants