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

Add new QUnit testing API. #232

Merged
merged 12 commits into from Jul 29, 2017

Conversation

@rwjblue
Member

rwjblue commented Jun 14, 2017

rendered

Related to (though somewhat diverged from) emberjs/ember-qunit#258.
Related to #119.
Intending to land together with #229.

rwjblue added some commits Jun 14, 2017

@stefanpenner

❤️

@trentmwillis

Overall, big 👍 on this RFC. A few nitty comments to ensure clarity while reading.

One thing that did strike me, that I feels needs to be better highlighted, is that the actual testing context API is changing as well as the test module setup API. The motivation mentions changes to moduleFor but doesn't call out that other APIs will also change (e.g., this.subject -> this.owner.lookup), which I think is rather critical because it makes migration less straightforward.

Show outdated Hide outdated text/0230-simplify-qunit-testing-api.md
Show outdated Hide outdated text/0230-simplify-qunit-testing-api.md
Show outdated Hide outdated text/0230-simplify-qunit-testing-api.md
@Turbo87

few minor comments, but in general : yes, please!! 👍

test('renders', async function(assert) {
assert.expect(1);
await this.render(hbs`{{pretty-color name="red"}}`);

This comment has been minimized.

@Turbo87

Turbo87 Jun 14, 2017

Member

Since when is this.render() async? What if the platform doesn't support async/await yet?

@Turbo87

Turbo87 Jun 14, 2017

Member

Since when is this.render() async? What if the platform doesn't support async/await yet?

This comment has been minimized.

@rwjblue

rwjblue Jun 14, 2017

Member

Since when is this.render() async?

Rendering a template has actually never been guaranteed to be synchronous. Future iterations of things in glimmer-vm will almost certainly take more advantage of async during rendering to allow the rendering engine to yield back to the browser to avoid blocking the main thread. Making this.render be a promise based API is a way to help ensure a change (that would help all apps in reality) doesn't troll all of our tests.

What if the platform doesn't support async/await yet?

Seems unrelated? The underlying implementation will be returning a promise. If the consuming application doesn't want to use async/await it would use promise chaining.

  test('renders', async function(assert) {
    assert.expect(1);

    return this.render(hbs`{{pretty-color name="red"}}`)
      .then(() => {
        assert.equal(this.$('.color-name').text(), 'red');
      });
  });
@rwjblue

rwjblue Jun 14, 2017

Member

Since when is this.render() async?

Rendering a template has actually never been guaranteed to be synchronous. Future iterations of things in glimmer-vm will almost certainly take more advantage of async during rendering to allow the rendering engine to yield back to the browser to avoid blocking the main thread. Making this.render be a promise based API is a way to help ensure a change (that would help all apps in reality) doesn't troll all of our tests.

What if the platform doesn't support async/await yet?

Seems unrelated? The underlying implementation will be returning a promise. If the consuming application doesn't want to use async/await it would use promise chaining.

  test('renders', async function(assert) {
    assert.expect(1);

    return this.render(hbs`{{pretty-color name="red"}}`)
      .then(() => {
        assert.equal(this.$('.color-name').text(), 'red');
      });
  });
import hbs from 'htmlbars-inline-precompile';
module('x-foo', function(hooks) {
setupRenderingTest(hooks);

This comment has been minimized.

@Turbo87

Turbo87 Jun 14, 2017

Member

IMHO we should pass the component name to the setup function here instead of relying on the module name, which seems a little brittle

@Turbo87

Turbo87 Jun 14, 2017

Member

IMHO we should pass the component name to the setup function here instead of relying on the module name, which seems a little brittle

This comment has been minimized.

@rwjblue

rwjblue Jun 14, 2017

Member

The component name is completely unused/unneeded without needs/unit options (which this API will not support). There is no reliance on the module name at all either.

@rwjblue

rwjblue Jun 14, 2017

Member

The component name is completely unused/unneeded without needs/unit options (which this API will not support). There is no reliance on the module name at all either.

import { setupTest } from 'ember-qunit';
module('x-foo', function(hooks) {
setupTest(hooks);

This comment has been minimized.

@Turbo87

Turbo87 Jun 14, 2017

Member

same as above. how does setupTest() know that we're talking about a component and what its name is?

@Turbo87

Turbo87 Jun 14, 2017

Member

same as above. how does setupTest() know that we're talking about a component and what its name is?

This comment has been minimized.

@rwjblue

rwjblue Jun 14, 2017

Member

It doesn't matter at all actually. Thats the beauty of removing the arbitrary resolver restrictions (in #229).

There will be a number of changes to the primitives in ember-test-helpers to support this nicely (for both ember-mocha and ember-qunit).

@rwjblue

rwjblue Jun 14, 2017

Member

It doesn't matter at all actually. Thats the beauty of removing the arbitrary resolver restrictions (in #229).

There will be a number of changes to the primitives in ember-test-helpers to support this nicely (for both ember-mocha and ember-qunit).

let Factory = this.owner.factoryFor('component:x-foo');
let subject = Factory.create({
name: 'something'
});

This comment has been minimized.

@Turbo87

Turbo87 Jun 14, 2017

Member

No this.subject() anymore?

@Turbo87

Turbo87 Jun 14, 2017

Member

No this.subject() anymore?

This comment has been minimized.

@rwjblue

rwjblue Jun 14, 2017

Member

No, we have a public API for looking up and instantiating factories (factoryFor), which is polyfilled nicely via ember-getowner-polyfill and ember-factory-for-polyfill.

Removing this.subject and the unit / needs options is how we avoid requiring the extra arguments to setupTest.

@rwjblue

rwjblue Jun 14, 2017

Member

No, we have a public API for looking up and instantiating factories (factoryFor), which is polyfilled nicely via ember-getowner-polyfill and ember-factory-for-polyfill.

Removing this.subject and the unit / needs options is how we avoid requiring the extra arguments to setupTest.

* ember-source
* ember-data
* ember-cli-legacy-blueprints
* others?

This comment has been minimized.

@Turbo87

Turbo87 Jun 14, 2017

Member

Might be worth mentioning that we are already doing the same thing for ember-mocha too

@Turbo87

Turbo87 Jun 14, 2017

Member

Might be worth mentioning that we are already doing the same thing for ember-mocha too

This comment has been minimized.

@rwjblue

rwjblue Jun 14, 2017

Member

Great point, updated!

@rwjblue

rwjblue Jun 14, 2017

Member

Great point, updated!

The work around is "simple" (if somewhat annoying), which is to "just nest another
level". The good news is that [Trent Willis](https://github.com/trentwillis) fixed
the underlying problem in [qunitjs/qunit#1188](https://github.com/qunitjs/qunit/pull/1188),
which should be released as 2.3.4 well before this RFC is merged.

This comment has been minimized.

@Turbo87

Turbo87 Jun 14, 2017

Member

so this is actually not an issue since we can just bump the QUnit dependency in ember-qunit right?

@Turbo87

Turbo87 Jun 14, 2017

Member

so this is actually not an issue since we can just bump the QUnit dependency in ember-qunit right?

This comment has been minimized.

@rwjblue

rwjblue Jun 14, 2017

Member

Confirm. I've spoken to @trentmwillis about it also, and I believe there shouldn't be a problem with getting a release out by the time this RFC is ready to be merged (which is a week or two at the minimum).

@rwjblue

rwjblue Jun 14, 2017

Member

Confirm. I've spoken to @trentmwillis about it also, and I believe there shouldn't be a problem with getting a release out by the time this RFC is ready to be merged (which is a week or two at the minimum).

}
```
### `setupTest`

This comment has been minimized.

@robbiepitts

robbiepitts Jun 14, 2017

It's unclear to me how setupTest, etc. will be able to access the tests' this when we are only passing in the hooks object. To illustrate what I'm talking about, this is what I am doing in Glimmer:

function setupRenderingTest(context, hooks) {
  context.render = function render(/* not important */) {
    // ...
  };

  // ...
}
module('Component: <hello-glimmer />', function(hooks) {
  setupRenderingTest(this, hooks);

  test('it renders', assert => {
    // ...
  });
});

Basically just wondering if the setupTest(hooks) signature is realistic or if it's going to need to be setupTest(this, hooks). Or maybe this is a detail beyond the scope of this RFC.

@robbiepitts

robbiepitts Jun 14, 2017

It's unclear to me how setupTest, etc. will be able to access the tests' this when we are only passing in the hooks object. To illustrate what I'm talking about, this is what I am doing in Glimmer:

function setupRenderingTest(context, hooks) {
  context.render = function render(/* not important */) {
    // ...
  };

  // ...
}
module('Component: <hello-glimmer />', function(hooks) {
  setupRenderingTest(this, hooks);

  test('it renders', assert => {
    // ...
  });
});

Basically just wondering if the setupTest(hooks) signature is realistic or if it's going to need to be setupTest(this, hooks). Or maybe this is a detail beyond the scope of this RFC.

This comment has been minimized.

@rwjblue

rwjblue Jun 14, 2017

Member

@robbiepitts - A basic implementation of this API is already done (see here), and does function properly without the context being passed in. I believe that the signature proposed here is realistic.

@rwjblue

rwjblue Jun 14, 2017

Member

@robbiepitts - A basic implementation of this API is already done (see here), and does function properly without the context being passed in. I believe that the signature proposed here is realistic.

This comment has been minimized.

@robbiepitts

robbiepitts Jun 14, 2017

Ohhh, cool. I didn't think of doing it that way.

@robbiepitts

robbiepitts Jun 14, 2017

Ohhh, cool. I didn't think of doing it that way.

rwjblue added some commits Jun 14, 2017

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 14, 2017

Member

@trentmwillis:

One thing that did strike me, that I feels needs to be better highlighted, is that the actual testing context API is changing as well as the test module setup API.

@Turbo87:

IMHO we should pass the component name to the setup function here instead of relying on the module name, which seems a little brittle
...
Since when is this.render() async?

Good points! I've just added a section to specifically call out significant changes from the current system.

Member

rwjblue commented Jun 14, 2017

@trentmwillis:

One thing that did strike me, that I feels needs to be better highlighted, is that the actual testing context API is changing as well as the test module setup API.

@Turbo87:

IMHO we should pass the component name to the setup function here instead of relying on the module name, which seems a little brittle
...
Since when is this.render() async?

Good points! I've just added a section to specifically call out significant changes from the current system.

rwjblue added some commits Jun 14, 2017

@hjdivad

hugely excited for this: 👍

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 15, 2017

Member

A few folks (e.g. @ebryn and @stefanpenner) have approached me with concerns around the hooks argument I have mentioned/used here. The concerns are generally an initial reaction to the QUnit nested modules API in general and not directly related to this RFC (other than it highlighting a new feature that they haven't used before).

The main concerns as I understood it are:

  • Teaching folks what hooks means is a bit more difficult because it does not represent the "test environment", but rather just a way to invoke the callbacks for before / beforeEach / after / afterEach.
  • Passing only hooks to the helper functions proposed in the RFC means that if we ever need to thread more information through, we either have to use hooks as a transport or change our API to add more arguments.
  • It seems somewhat impossible to communicate across multiple helpers (again without using hooks as a state/transport mechanism).

I've kicked off a conversation over with the QUnit folks in qunitjs/qunit#1200. If that PR were merged this proposal would be modified to the following syntax:

// current proposal
module('x-foo', function(hooks) {
  setupRenderingTest(hooks);
  // ....snip....
});

// after qunitjs/qunit#1200
module('x-foo', function(hooks) {
  setupRenderingTest(this);
  // ....snip....
});

I will update the RFC to list this as an unanswered question, but I personally do not find this to be a blocking issue (we'll see how others feel). This RFC is mostly just leveraging what the underlying test framework has to offer (which is one of the primary objectives in the motivation section).

Member

rwjblue commented Jun 15, 2017

A few folks (e.g. @ebryn and @stefanpenner) have approached me with concerns around the hooks argument I have mentioned/used here. The concerns are generally an initial reaction to the QUnit nested modules API in general and not directly related to this RFC (other than it highlighting a new feature that they haven't used before).

The main concerns as I understood it are:

  • Teaching folks what hooks means is a bit more difficult because it does not represent the "test environment", but rather just a way to invoke the callbacks for before / beforeEach / after / afterEach.
  • Passing only hooks to the helper functions proposed in the RFC means that if we ever need to thread more information through, we either have to use hooks as a transport or change our API to add more arguments.
  • It seems somewhat impossible to communicate across multiple helpers (again without using hooks as a state/transport mechanism).

I've kicked off a conversation over with the QUnit folks in qunitjs/qunit#1200. If that PR were merged this proposal would be modified to the following syntax:

// current proposal
module('x-foo', function(hooks) {
  setupRenderingTest(hooks);
  // ....snip....
});

// after qunitjs/qunit#1200
module('x-foo', function(hooks) {
  setupRenderingTest(this);
  // ....snip....
});

I will update the RFC to list this as an unanswered question, but I personally do not find this to be a blocking issue (we'll see how others feel). This RFC is mostly just leveraging what the underlying test framework has to offer (which is one of the primary objectives in the motivation section).

@Turbo87

This comment has been minimized.

Show comment
Hide comment
@Turbo87

Turbo87 Jun 16, 2017

Member

@rwjblue I'm not sure I understand that last comment about hooks properly yet. In ember-mocha we don't need to pass this into the setup functions at all since we only need this in the setup/teardown functions, which are bound to the correct context automatically... maybe I'm misunderstanding something here 🤔

Member

Turbo87 commented Jun 16, 2017

@rwjblue I'm not sure I understand that last comment about hooks properly yet. In ember-mocha we don't need to pass this into the setup functions at all since we only need this in the setup/teardown functions, which are bound to the correct context automatically... maybe I'm misunderstanding something here 🤔

rwjblue added some commits Jun 16, 2017

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 16, 2017

Member

@Turbo87:

In ember-mocha we don't need to pass this into the setup functions at all since we only need this in the setup/teardown functions, which are bound to the correct context automatically

Yep, I absolutely understand how it works in ember-mocha. Unlike mocha, QUnit does not provide global functions for before/beforeEach/afterEach/after. The only way to register these callbacks in a QUnit setting is to pass in the first argument of the module callback (which has been named hooks in the examples for this RFC as well as a few examples on qunitjs.com).

Member

rwjblue commented Jun 16, 2017

@Turbo87:

In ember-mocha we don't need to pass this into the setup functions at all since we only need this in the setup/teardown functions, which are bound to the correct context automatically

Yep, I absolutely understand how it works in ember-mocha. Unlike mocha, QUnit does not provide global functions for before/beforeEach/afterEach/after. The only way to register these callbacks in a QUnit setting is to pass in the first argument of the module callback (which has been named hooks in the examples for this RFC as well as a few examples on qunitjs.com).

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jun 16, 2017

Member

Another possible mitigation to the strangeness of the word hooks as the argument, is to use module. After discussing with the QUnit folks, it seems that this argument represents the "module context".

This would change the examples here in this RFC to be:

module('x-foo', function(module) {
  setupRenderingTest(module);
  // ....snip....
});

The mental model here would be:

The callback receives the module instance that was created so that you can add before/beforeEach/afterEach/after callbacks.

tldr; I think module works much better here...

Member

rwjblue commented Jun 16, 2017

Another possible mitigation to the strangeness of the word hooks as the argument, is to use module. After discussing with the QUnit folks, it seems that this argument represents the "module context".

This would change the examples here in this RFC to be:

module('x-foo', function(module) {
  setupRenderingTest(module);
  // ....snip....
});

The mental model here would be:

The callback receives the module instance that was created so that you can add before/beforeEach/afterEach/after callbacks.

tldr; I think module works much better here...

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jul 1, 2017

Member

This was discussed at the 2017-06-30 core team meeting, and given that the responses by folks are overwhelmingly positive it is ready to advance to final comment period.

Member

rwjblue commented Jul 1, 2017

This was discussed at the 2017-06-30 core team meeting, and given that the responses by folks are overwhelmingly positive it is ready to advance to final comment period.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jul 8, 2017

Member

QUnit 2.4.0 was just released (thanks @trentmwillis!) which includes the required changes to enable this API.

Member

rwjblue commented Jul 8, 2017

QUnit 2.4.0 was just released (thanks @trentmwillis!) which includes the required changes to enable this API.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Jul 29, 2017

Member

No new information was identified during final comment period, thanks to everyone for the detailed review and help working through this. Let's get it done!

Member

rwjblue commented Jul 29, 2017

No new information was identified during final comment period, thanks to everyone for the detailed review and help working through this. Let's get it done!

@rwjblue rwjblue merged commit ecc1c1b into emberjs:master Jul 29, 2017

@rwjblue rwjblue deleted the rwjblue:new-testing-api branch Jul 29, 2017

rwjblue added a commit to emberjs/ember-qunit that referenced this pull request Oct 17, 2017

Move legacy testing system into legacy-2-x subfolder.
This is in prep for the work needed to support the new testing API's
proposed in emberjs/rfcs#232.
test('renders', async function(assert) {
assert.expect(1);
await this.render(hbs`{{pretty-color name="red"}}`);

This comment has been minimized.

@stephenh

stephenh Nov 11, 2017

@rwjblue apologies for wandering by, but seems like continuing setupRenderingTest-injects-render-into-this is continuing the "change objects at runtime" style of ember's JS roots.

If a goal (of some subset of the users/disclaimer IANAE) is to have better TS support, it seems like these sort of "suddenly show up on this" methods will be inherently untypeable, and instead render should be a the static import (like test, module, etc.) or else called against some non-this variable that can be appropriately typed, e.g. returned from the setupRenderingTest method/something like that.

Granted, no idea what compromises you have to make for backwards compatibility, e.g. if having users move from this.render to render or foo.render is just a no-go, but if you're making a big change, seems like moving towards typeable-if-you-want APIs/DSLs would be worthwhile.

@stephenh

stephenh Nov 11, 2017

@rwjblue apologies for wandering by, but seems like continuing setupRenderingTest-injects-render-into-this is continuing the "change objects at runtime" style of ember's JS roots.

If a goal (of some subset of the users/disclaimer IANAE) is to have better TS support, it seems like these sort of "suddenly show up on this" methods will be inherently untypeable, and instead render should be a the static import (like test, module, etc.) or else called against some non-this variable that can be appropriately typed, e.g. returned from the setupRenderingTest method/something like that.

Granted, no idea what compromises you have to make for backwards compatibility, e.g. if having users move from this.render to render or foo.render is just a no-go, but if you're making a big change, seems like moving towards typeable-if-you-want APIs/DSLs would be worthwhile.

This comment has been minimized.

@rwjblue

rwjblue Nov 11, 2017

Member

Subsequent to this RFC I implemented the helpers as importables (in fact that is what the codemod actually does), there is more written on this in #268.

@rwjblue

rwjblue Nov 11, 2017

Member

Subsequent to this RFC I implemented the helpers as importables (in fact that is what the codemod actually does), there is more written on this in #268.

This comment has been minimized.

@stephenh

stephenh Nov 11, 2017

Ah great, thanks! I'd read #268 and noticed it was that way there, but didn't put 2+2 together to realize that meant these were older examples that were supplanted by #268's.

@stephenh

stephenh Nov 11, 2017

Ah great, thanks! I'd read #268 and noticed it was that way there, but didn't put 2+2 together to realize that meant these were older examples that were supplanted by #268's.

@rwjblue rwjblue referenced this pull request Dec 17, 2017

Merged

Ember 2.18 Release Blog Post #3092

4 of 13 tasks complete

rwjblue added a commit to rwjblue/ember-cli that referenced this pull request Jan 11, 2018

Remove unused testing helper files.
As of ember-source@3.0.0 (and ember-data@3.0.0) the testing blueprints
are automatically emitting emberjs/rfcs#232 or emberjs/rfcs#268
compatible output. With those, these helpers are no longer used for new
apps.

Existing apps should only delete these files once they have migrated to
the new testing system...

rwjblue added a commit to rwjblue/ember-cli that referenced this pull request Jan 11, 2018

Remove unused testing helper files.
As of ember-source@3.0.0 (and ember-data@3.0.0) the testing blueprints
are automatically emitting emberjs/rfcs#232 or emberjs/rfcs#268
compatible output. With those, these helpers are no longer used for new
apps.

Existing apps should only delete these files once they have migrated to
the new testing system...

rwjblue added a commit to rwjblue/ember-cli that referenced this pull request Jan 11, 2018

Remove unused testing helper files.
As of ember-source@3.0.0 (and ember-data@3.0.0) the testing blueprints
are automatically emitting emberjs/rfcs#232 or emberjs/rfcs#268
compatible output. With those, these helpers are no longer used for new
apps.

Existing apps should only delete these files once they have migrated to
the new testing system...

rwjblue added a commit to rwjblue/ember-cli that referenced this pull request Jan 11, 2018

Remove unused testing helper files.
As of ember-source@3.0.0 (and ember-data@3.0.0) the testing blueprints
are automatically emitting emberjs/rfcs#232 or emberjs/rfcs#268
compatible output. With those, these helpers are no longer used for new
apps.

Existing apps should only delete these files once they have migrated to
the new testing system...

rwjblue added a commit to rwjblue/ember-cli that referenced this pull request Jan 12, 2018

Remove unused testing helper files.
As of ember-source@3.0.0 (and ember-data@3.0.0) the testing blueprints
are automatically emitting emberjs/rfcs#232 or emberjs/rfcs#268
compatible output. With those, these helpers are no longer used for new
apps.

Existing apps should only delete these files once they have migrated to
the new testing system...

rwjblue added a commit to rwjblue/ember-cli that referenced this pull request Jan 12, 2018

Remove embertest from ESLint configuration.
As of Ember 3.0 the new testing APIs introduced in emberjs/rfcs#232 and
emberjs/rfcs#268 are enabled and used by default. In these APIs no
globals are used, therefore this extra `tests/` override is removed.

This specifically removes the following globals from being allowed:

* `andThen`
* `click`
* `currentPath`
* `currentRouteName`
* `currentURL`
* `fillIn`
* `find`
* `findWithAssert`
* `keyEvent`
* `pauseTest`
* `resumeTest`
* `triggerEvent`
* `visit`
* `wait`

rwjblue added a commit to rwjblue/ember-cli that referenced this pull request Jan 13, 2018

Remove embertest from ESLint configuration.
As of Ember 3.0 the new testing APIs introduced in emberjs/rfcs#232 and
emberjs/rfcs#268 are enabled and used by default. In these APIs no
globals are used, therefore this extra `tests/` override is removed.

This specifically removes the following globals from being allowed:

* `andThen`
* `click`
* `currentPath`
* `currentRouteName`
* `currentURL`
* `fillIn`
* `find`
* `findWithAssert`
* `keyEvent`
* `pauseTest`
* `resumeTest`
* `triggerEvent`
* `visit`
* `wait`

rwjblue added a commit to rwjblue/builds that referenced this pull request Jan 14, 2018

@rwjblue rwjblue referenced this pull request Jan 14, 2018

Merged

Update all the things... #58

locks added a commit to ember-learn/builds that referenced this pull request Jan 16, 2018

Update all the things... (#58)
* updated packages and ember-cli-deploy

(cherry picked from commit e4042d8)

* Bring back `.env.example`.

* Update ember-cli from 2.14 to 2.18 blueprint.

* Remove bower and phantom references.

* Fix linting failures after eslint config updates.

* yarn upgrade

* Loosen dependencies (all use `^` now).

* Update ember-moment and ember-cli-moment-shim to latest.

* Remove legacy zeroclipboard app.imports.

* Use `--no-sandbox` flag with Chrome on CI.

* Update tests to emberjs/rfcs#232 format.

thetimothyp pushed a commit to thetimothyp/ember-cli that referenced this pull request Jan 19, 2018

Remove unused testing helper files.
As of ember-source@3.0.0 (and ember-data@3.0.0) the testing blueprints
are automatically emitting emberjs/rfcs#232 or emberjs/rfcs#268
compatible output. With those, these helpers are no longer used for new
apps.

Existing apps should only delete these files once they have migrated to
the new testing system...

thetimothyp pushed a commit to thetimothyp/ember-cli that referenced this pull request Jan 19, 2018

Remove embertest from ESLint configuration.
As of Ember 3.0 the new testing APIs introduced in emberjs/rfcs#232 and
emberjs/rfcs#268 are enabled and used by default. In these APIs no
globals are used, therefore this extra `tests/` override is removed.

This specifically removes the following globals from being allowed:

* `andThen`
* `click`
* `currentPath`
* `currentRouteName`
* `currentURL`
* `fillIn`
* `find`
* `findWithAssert`
* `keyEvent`
* `pauseTest`
* `resumeTest`
* `triggerEvent`
* `visit`
* `wait`

@GavinJoyce GavinJoyce referenced this pull request Jan 29, 2018

Merged

Module-unification component blueprint #16043

13 of 13 tasks complete

apucher added a commit to linkedin/pinot that referenced this pull request Mar 19, 2018

[TE] upgraded all tests syntax
What's new:
updating the old moduleFor syntax to the newer syntax (used in Ember 3.0) as proposed in emberjs/rfcs#232
Tests:
All tests still passing 268/268

@GavinJoyce GavinJoyce referenced this pull request Apr 3, 2018

Closed

[WIP] Update ember-cli #16459

0 of 1 task complete

npawar added a commit to linkedin/pinot that referenced this pull request Apr 6, 2018

[TE] upgraded all tests syntax
What's new:
updating the old moduleFor syntax to the newer syntax (used in Ember 3.0) as proposed in emberjs/rfcs#232
Tests:
All tests still passing 268/268

theseyi added a commit to theseyi/WhereHows that referenced this pull request Aug 9, 2018

theseyi added a commit to theseyi/WhereHows that referenced this pull request Aug 10, 2018

migrates acceptance to application tests, unit tests sources from old…
…er moduleFor* syntax of ember-qunit@2 to newer syntax proposed by emberjs/rfcs#232. removes ember-native-dom-helpers in favor of @ember/test-helpers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment