Gathering detailed insights and metrics for ember-cli-blueprint-test-helpers
Gathering detailed insights and metrics for ember-cli-blueprint-test-helpers
Gathering detailed insights and metrics for ember-cli-blueprint-test-helpers
Gathering detailed insights and metrics for ember-cli-blueprint-test-helpers
Test helpers for testing ember-cli blueprints
npm install ember-cli-blueprint-test-helpers
Typescript
Module System
Min. Node Version
Node Version
NPM Version
82.8
Supply Chain
94
Quality
79.2
Maintenance
100
Vulnerability
97.6
License
JavaScript (100%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
23 Stars
450 Commits
15 Forks
14 Watchers
20 Branches
36 Contributors
Updated on Jan 28, 2025
Latest Version
0.19.2
Package Id
ember-cli-blueprint-test-helpers@0.19.2
Unpacked Size
48.23 kB
Size
10.05 kB
File Count
21
NPM Version
5.6.0
Node Version
8.11.4
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
test helpers for ember-cli blueprints
ember install ember-cli-blueprint-test-helpers
It should be noted that ember-cli-blueprint-test-helpers
currently
only works for testing blueprints inside addon projects.
The blueprint tests can be run by:
node_modules/.bin/mocha node-tests --recursive
For convenience you should add the following to your package.json
:
1"scripts": { 2 "nodetest": "mocha node-tests --recursive" 3}
to be able to use npm run nodetest
to run the tests.
Generate a blueprint test scaffold using the blueprint-test
generator:
ember generate blueprint-test my-blueprint
which will generate a test file at node-tests/blueprints/my-blueprint-test.js
.
1describe('Acceptance: ember generate and destroy my-blueprint', function() { 2 // create and destroy temporary working directories 3 setupTestHooks(this); 4 5 it('my-blueprint foo', function() { 6 const args = ['my-blueprint', 'foo']; 7 8 // create a new Ember.js app in the working directory 9 return emberNew() 10 11 // then generate and destroy the `my-blueprint` blueprint called `foo` 12 .then(() => emberGenerateDestroy(args, (file) => { 13 14 // and run some assertions in between 15 expect(file('path/to/file.js')) 16 .to.contain('file contents to match') 17 .to.contain('more file contents\n'); 18 })); 19 20 // magically done for you: assert that the generated files are destroyed again 21 }); 22});
or more explicitly:
1describe('Acceptance: ember generate and destroy my-blueprint', function() { 2 // create and destroy temporary working directories 3 setupTestHooks(this); 4 5 it('my-blueprint foo', function() { 6 const args = ['my-blueprint', 'foo']; 7 8 // create a new Ember.js app in the working directory 9 return emberNew() 10 11 // then generate the `my-blueprint` blueprint called `foo` 12 .then(() => emberGenerate(args)) 13 14 // then assert that the files were generated correctly 15 .then(() => expect(file('path/to/file.js')) 16 .to.contain('file contents to match') 17 .to.contain('more file contents\n')) 18 19 // then destroy the `my-blueprint` blueprint called `foo` 20 .then(() => emberDestroy(args)) 21 22 // then assert that the files were destroyed correctly 23 .then(() => expect(file('path/to/file.js')).to.not.exist); 24 }); 25});
if your blueprints support the new
MU file structure, you can test them
using this option: { ìsModuleUnification: true }
1describe('Acceptance: ember generate and destroy my-blueprint', function() { 2 // create and destroy temporary working directories 3 setupTestHooks(this); 4 5 it('my-blueprint foo', function() { 6 const args = ['my-blueprint', 'foo']; 7 8 // create a new Ember.js app in the working directory 9 // this app will have MU file structure, namely a `src` directory 10 return emberNew({ isModuleUnification: true }) 11 12 // then generate the `my-blueprint` blueprint called `foo` 13 .then(() => emberGenerate(args, { isModuleUnification: true })) 14 15 // then assert that the files were generated correctly 16 .then(() => expect(file('path/to/file.js')) 17 .to.contain('file contents to match') 18 .to.contain('more file contents\n')) 19 20 // then destroy the `my-blueprint` blueprint called `foo` 21 .then(() => emberDestroy(args, { isModuleUnification: true })) 22 23 // then assert that the files were destroyed correctly 24 .then(() => expect(file('path/to/file.js')).to.not.exist); 25 }); 26});
This project exports two major API endpoints for you to use:
require('ember-cli-blueprint-test-helpers/chai')
This endpoint exports the Chai assertion library including the chai-as-promised and chai-files plugins
require('ember-cli-blueprint-test-helpers/helpers')
This endpoint exports the functions mentioned in the following API reference
setupTestHooks(scope, options)
Prepare the test context for the blueprint tests.
Parameters:
{Object} scope
the test context (i.e. this
){Object} [options]
optional parameters{Number} [options.timeout=20000]
the test timeout in milliseconds{Object} [options.tmpenv]
object containing info about the temporary directory for the test.{String} [options.cliPath='ember-cli']
path to the ember-cli
dependency{Boolean} [options.disabledTasks=['addon-install', 'bower-install', 'npm-install']]
override the mocked installs
Defaults to lib/helpers/tmp-env.js
Returns: {Promise}
emberNew(options)
Create a new Ember.js app or addon in the current working directory.
Parameters:
{Object} [options]
optional parameters{String} [options.target='app']
the type of project to create (app
, addon
or in-repo-addon
){Boolean} [options.isModuleUnification=true]
a toggle to use MU file structureReturns: {Promise}
emberGenerate(args, options)
Run a blueprint generator.
Parameters:
{Array.<String>} args
arguments to pass to ember generate
(e.g. ['my-blueprint', 'foo']
){Object} [options]
optional parameters{Boolean} [options.isModuleUnification=true]
a toggle to use MU file structureReturns: {Promise}
emberDestroy(args, options)
Run a blueprint destructor.
Parameters:
{Array.<String>} args
arguments to pass to ember destroy
(e.g. ['my-blueprint', 'foo']
){Object} [options]
optional parameters{Boolean} [options.isModuleUnification=true]
a toggle to use MU file structureReturns: {Promise}
emberGenerateDestroy(args, assertionCallback, options)
Run a blueprint generator and the corresponding blueprint destructor while checking assertions in between.
Parameters:
{Array.<String>} args
arguments to pass to ember generate
(e.g. ['my-blueprint', 'foo']
){Function} assertionCallback
the callback function in which the assertions should happen{Object} [options]
optional parameters{Boolean} [options.isModuleUnification=true]
a toggle to use MU file structureReturns: {Promise}
modifyPackages(packages)
Modify the dependencies in the package.json
file of the test project.
Parameters:
{Array.<Object>} packages
the list of packages that should be added,
changed or removedsetupPodConfig(options)
Setup usePods
in .ember-cli
and/or podModulePrefix
in environment.js
.
Parameters:
{Object} [options]
optional parameters{Boolean} [options.usePods]
add usePods
in .ember-cli
{Boolean} [options.podModulePrefix]
set npodModulePrefix
to app/pods
in config/environment.js
This project is licensed under the MIT License.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
Found 3/21 approved changesets -- score normalized to 1
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
license file not detected
Details
Reason
project is not fuzzed
Details
Reason
security policy file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
72 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More