alexander-alvarez

import Ember from 'ember';

export default Ember.Controller.extend({
  appName: 'Ember Twiddle',
  anArray: Ember.A([]),
  actions: {
    update(){
      this.get('anArray').pushObject('hello hello'); 
    }
  }

alexander-alvarez

BACKGROUND

In the [RFC-232] , [RFC-268] style tests we wanted to simplify some of the abstractions around testing, so it is simpler to implement, and the ecosystem gets out of the way more. This led to a paradigm shift from "I'm doing an x-style test", to "I'm testing X and need Y and Z configured in order to do it". E.g moduleForComponent -> setupRenderingTest, moduleForAcceptance -> setupApplicationTest.

In implementing the new style blueprints for ember-data, I'd like to understand where we'd like the ember-data testing story to go, and if this is the right point to do so, since we will be modifying those files.

As such, what are analagous concepts we could introduce for ember-data? Does it make sense to introduce these analagous concepts?

Ember Data Classes Who's Testing Use Cases We Need To Ensure We Address

• Adapters, Models, Serializers, Transforms

alexander-alvarez

We need to implement changes in blueprints and docs realted to [RFC 232] and [RFC 268]. (Some background for those unfamiliar http://rwjblue.com/2017/10/23/ember-qunit-simplication/)

As of ember-cli-qunit@^4.1.1 (which is in the default blueprint as of ember-cli@2.17), we can implement the "Simplified QUnit" style tests in all tests except for acceptance tests. In a future release of ember-qunit (likely 3.2.x), we will be able to leverage the implementation of setupApplicationTest from [RFC 268] for use in acceptance-tests. Once these changes are implemented upstream, we must implement the blueprint updates. Currently, we have no way to generate these test files but we can run the [ember-qunit-codemod] to migrate test files and continue to iterate on the final output in the blueprint specific pull requests.

The desired behavior when generating testing blueprints is to, generate "Simplified QUnit" style tests if supported by the host app. We have several tasks below to extend the blueprints to su

alexander-alvarez

{
  "name": "app",
  "version": "1.2.1",
  "description": "app",
  "directories": {
    "doc": "doc",
    "test": "tests"
  },
  "devDependencies": {
    "@types/ember": "^2.7.38",

alexander-alvarez

import { module, test } from 'ember-qunit';
import run from 'ember-runloop'
import EmberObject from 'ember-object'
import RSVP from 'rsvp';

import { all } from 'ember-concurrency';
import { BufferedChannel } from 'pool/classes';

module('Unit | Utility | BufferedChannel');

alexander-alvarez

import Ember from 'ember';
import {task, timeout} from 'ember-concurrency';

const { computed } = Ember;

export default Ember.Component.extend({
  
  requiredInputA: null,
  requiredInputB: null,
  hasRequiredInputA: computed.bool('requiredInputA'),

alexander-alvarez

import Ember from 'ember';

export default Ember.Component.extend({
});

alexander-alvarez

import Ember from 'ember';

export default Ember.Controller.extend({
  appName: 'Ember Twiddle'
});

alexander-alvarez

import Ember from 'ember';

export default Ember.Controller.extend({
  appName: 'Ember Twiddle',
  router: Ember.inject.service()
});

alexander-alvarez

import Ember from 'ember';
import {task, timeout} from 'ember-concurrency';

export default Ember.Controller.extend({
  appName: 'Ember Twiddle',
  
  typeAheadTask: task(function * (value) {
    yield timeout(500);
    return value
  }), // you can cancel or whatever you like