ember-cli-blueprint-test-helpers

ember-cli-blueprint-test-helpers

About

ember-cli-blueprint-test-helpers contains several test helpers for testing blueprints.

Usage

Install ember-cli-blueprint-test-helpers

Running Tests

To run the blueprint tests, run node node-tests/nodetest-runner.js. For convenience and CI purposes you can add the following to your package.json:

"scripts": {
  "nodetest": "node node-tests/nodetest-runner.js"
}

Then you can use npm run nodetest to run.

Generating Blueprint Tests

Generate a blueprint test scaffold using the blueprint-test blueprint. ember g blueprint-test my-blueprint

The blueprint test will be generated inside the node-tests/blueprint folder as:

  node-tests/blueprints/my-blueprint-nodetest.js

The minimum common setup is in the generated test, setup for generating and destroying a blueprint in one test.

Test Setup

The setupTestHooks convenience method sets up a blueprint test with a timeout as well as before, after, beforeEach, and afterEach hooks:

describe('Acceptance: ember generate', function() {
  // pass in test instance, and an optional options object.
  setupTestHooks(this, {timeout: 1000});

If you need to override or add to any of the hooks, you may pass a function in the options. The options supported are:

• timeout (number): Duration before test times out.
• tmpenv (tmpenv object): Object containing info about the temporary directory for the test. Defaults to lib/helpers/tmp-env.js
• before (function): Hook to execute code at the beginning of the before function.
• after (function): Hook to execute code at the beginning of the after function.
• beforeEach (function): Hook to execute code at the beginning of the beforeEach function.
• afterEach (function): Hook to execute code at the beginning of the afterEach function.

Generate and Destroy Test Helpers

Use generate, destroy, or generateAndDestroy to run a test.

All three methods take the following signature: commandArgs (array), options (object)

The commandArgs should contain any commandline properties and options that would be passed to a generate or destroy command.

The options should contain a files object, as well as any of the following options:

• usePods (boolean): Sets up .ember-cli file with "usePods": true. Default: false

• podModulePrefix (boolean): Sets up config/environment.js with 'app/pods' as the podModulePrefix. Default: false

• skipInit (boolean): Skips the temporary project init step for situations where the project has already been setup. Most commonly used when generating inside the afterGenerate hook.

• target (string): Defines the type of project to setup for the test. Recognized values: 'app', 'addon', 'inRepoAddon'

• packages (array): A list of packages that should be removed from or added to the package.json file after the project has been set up (only affects the test this option is set for). Example:

  packages: [
    { name: 'ember-cli-qunit', delete: true },
    { name: 'ember-cli-mocha', dev: true, version: '~1.0.2' }
  ]
  

• files (array): Array of files to assert, represented by objects with file, exists, contains, or doesNotContain properties. Example object:

  files: [
    {
      file: 'path-to-file.js', 
      contains: ['file contents to compare'], 
      doesNotContain: ['file contents that shouldn\'t be present'], 
      exists: true //default true
    }
  ]
  

• throws (regexp / / or object): Expected error message or excerpt to assert. Optionally, can be an object containing a message and type property. The type is a string of the error name. Example RegExp:

  /Expected error message text./
  

Example object:

{
  message: /Expected message/, 
  type: 'SilentError'
}

• beforeGenerate (function): Hook to execute before generating blueprint. Can be used for additional setup and assertions.
• afterGenerate (function): Hook to execute after generating blueprint. Can be used for additional setup and assertions.
• beforeDestroy (function): Hook to execute before destroying blueprint. Can be used for additional setup and assertions.
• afterDestroy (function): Hook to execute before destroying blueprint. Can be used for additional teardown and assertions.

Example Tests

The following is a basic test, asserting my-blueprint generated the files in the files array and that their content matches, and then that the blueprint was destroyed and that the files in the files array were properly removed.

var setupTestHooks     = require('ember-cli-blueprint-test-helpers/lib/helpers/setup');
var BlueprintHelpers   = require('ember-cli-blueprint-test-helpers/lib/helpers/blueprint-helper');
var generateAndDestroy = BlueprintHelpers.generateAndDestroy;

describe('Acceptance: ember generate and destroy blueprint', function() {
  setupTestHooks(this);

  it('blueprint test', function() {
    return generateAndDestroy(['my-blueprint', 'foo'], {
      files: [
        {
          file: 'path/to/file.js',
          contains: [
            'file contents to match',
            'more file contents\n'
          ]
        }
      ]
    });
  });

To assert that an error is thrown when incorrect input is used, you can use the throws option. The throws option simply requires a regex of the full or partial error message.

it('adapter application cannot extend from --base-class=application', function() {
  return generateAndDestroy(['adapter', 'application', '--base-class=application'], {
    throws: /Adapters cannot extend from themself/
  });
});

You can also pass an object containing the message and error type.

it('adapter application cannot extend from --base-class=application', function() {
  return generateAndDestroy(['adapter', 'application', '--base-class=application'], {
    throws: { 
      message: /Adapters cannot extend from themself/,
      type: 'SilentError'
    }
  });
});

To generate another blueprint beforehand, you can use the afterGenerate hook to do your actual assertions, like in the example below. Be sure to include the skipInit option inside the afterGenerate hook to prevent re-initializing the temporary project, which can lead to problems.

it('adapter extends from application adapter if present', function() {
  return generateAndDestroy(['adapter', 'application'], {
    afterGenerate: function() {
      return generateAndDestroy(['adapter', 'foo'], {
        // prevents this second generateAndDestroy from running init
        skipInit: true,
        files: [
          {
            file:'app/adapters/foo.js',
            contains: [
              "import ApplicationAdapter from './application';"
            ]
          }
        ]
      });
    }
  });
});

To setup a test project with a podModulePrefix or usePods setting, use the following options:

it('blueprint test', function() {
  return generateAndDestroy(['my-blueprint', 'foo'], {
    usePods: true,
    podModulePrefix: true
  });
});

To test generating into addons, in-repo-addons, and dummy projects, you can use the target option:

it('blueprint test', function() {
  return generateAndDestroy(['my-blueprint', 'foo'], {
    // supported options are 'app', 'addon', and 'inRepoAddon'
    target: 'addon'
  });
});

Changelog

v0.9.0 (2016-02-25)

Full Changelog

Implemented enhancements:

• Add "packages" option #31 (Turbo87)
• remove unneccessary lodash dependency #21 (jcope2013)

Fixed bugs:

• README: Fix broken "scripts" instruction #26 (Turbo87)
• blueprints/blueprint-test: Remove EOL import #24 (Turbo87)
• Fixes #19 use expect().to.be.true in assertions #20 (trabus)

Closed issues:

• Remove "console.log" statements #30
• Add "testFramework" option #27
• expect(...) is not complete #19
• Document skipInit option #13

Merged pull requests:

• Added blueprint-helpers tests #32 (trabus)
• Add missing .travis.yml file #29 (Turbo87)
• Use ESLint for style and code smell checking #25 (Turbo87)
• README: Use syntax highlighting #23 (Turbo87)
• Update docs #22 (trabus)