Expose importable helper functions.

[rwjblue]

These functions can be used instead of repeating this. throughout the testing code.

Example:

import { module, test } from 'qunit';
import { setupRenderingTest, render } from 'ember-qunit';
import hbs from 'htmlbars-inline-precompile';

module('x-foo', function(hooks) {
  setupRenderingTest(hooks);

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

    await render(hbs`{{pretty-color name="red"}}`);

    assert.equal(this.element.querySelector('.color-name').textContent, 'red');
  });
});

This is essentially the compromise made with the rest of the core team while working on the the "Grand Unified Testing RFC". The helpers will continue to live on this (for easy discoverability), but are also importable (for cleaner looking tests). Using the non this. form of helpers obviously means that we cannot run concurrent tests, but that is extremely unlikely to work anyways.

[Turbo87]

What were the arguments leading to this decision?

[rwjblue]

@Turbo87 roughly that the following "rightward" shift is something we can avoid:

test('foo', function(assert) {
  await this.visit('/some-path');
  await this.click('.some-link');
  await this.fillIn('.other-thing', 'derpy');
  await this.click('.submit');
  
   // assertions here
});

In the new system we are adding both await and this. which essentially shifts all lines 10 chars rightward.

Exposing the importable helpers (that simply defer to the this.* methods as in this PR) allows for the following API, while still being much less magical than today's acceptance test helpers:

import {
  visit,
  click,
  fillIn
} from 'ember-qunit';

// ...snip...
test('foo', function(assert) {
  await visit('/some-path');
  await click('.some-link');
  await fillIn('.other-thing', 'derpy');
  await click('.submit');
  
  // assertions here
});

[rwjblue]

I was a strong advocate for leaving the helper methods on the test context for discoverability, others were strongly opposed to the aesthetic of the rightward shift (as mentioned above). So I proposed this compromise (which satisfies both camps)...

[Turbo87]

While render and clearRender make sense to me I'm not yet convinced about the element binding. In this case it has been this.element before already so the right shift argument doesn't count here, and consistency isn't given either because element is a binding/variable/property/whatever, not a helper function. And if we start to expose basically any property on the context then at some point we'll end up with a global owner, a global get(), a global set(), ...

[rwjblue]

Sounds good. I’ll remove element.

[rwjblue]

We could also expose element as a function (testElement() or getElement() or something), but I’m totally fine with punting in that for now.