Skip to content

Test "new" and "addon" commands output against fixtures#7595

Closed
ro0gr wants to merge 7 commits intoember-cli:masterfrom
ro0gr:new-test-fixturified
Closed

Test "new" and "addon" commands output against fixtures#7595
ro0gr wants to merge 7 commits intoember-cli:masterfrom
ro0gr:new-test-fixturified

Conversation

@ro0gr
Copy link
Copy Markdown
Contributor

@ro0gr ro0gr commented Feb 2, 2018

Supersedes #7557
It's needed to safely experiment with blueprints specifically mu-app blueprint.

There are few issues with the current confirmBlueprinted approach:

  • it relies on blueprint internals:
    • it uses Blueprint files/ directory as a single source of truth. So if we have some custom logic which filters/adds some files confirmBlueprinted doesn't allow us to test this.
    • it relies on Blueprint.renamedFiles which is bad cause I believe that tests should not rely on the tested units.
  • it doesn't test the file contents. Only file file paths.

I think the main issue with this approach is that if we remove half of the blueprint files then test will continue to pass.

Also there are few more concerns:

  • we want to test app, addon, and mu-app w/ and w/o ember-welcome. But we don't want to have the whole project fixture for each of these cases. We need a way to use a default fixture and just apply small patches to it right in the test(w/o additional fixture folder).
  • mu-app and app blueprint output have lots of common parts. It would be great not to duplicate this files. If we re-use app fixture for mu-app we can be more confident that mu-app blueprint is in sync with the app.

In order to address these issues I've introduced 2 new helpers:

loadProjectFixture(fixturePaths, options)

Loads the fixture from a single or multiple paths:

// load npm app fixture
const npmApp = options => projectFixture('app/npm', options);
// load fixtures sequentially and merge them
const yarnAddon = options => projectFixture([npmAddon(), 'addon/yarn'], options);

Under the hood it uses fixturify to load the files but the result is flattened for the sake of a better diff results.

loadProjectFixture also allows to filter result with files option which accepts minimatch patterns:

const muApp = options =>projectFixture([
  npmApp({ files: ['!app/**'] }), // load regular app but "app/" directory
  'module-unification-app/npm', // it contains only mu specific parts
], options);

And finally we can patch resulting files with a patches option:

muApp({
  patches: {
    'vendor/script.js': '// test comment',
    'package.json': function(stringContent) {
        return stringContent;
     }
  }
})

expectProject(expectedProjectName, fixture)

It's supposed to check that the current dir has an expected name and all the file content are equal to the fixture content. It prints

  • a diff for each conflicting file
  • list of missing and extra files if any.

"ember-cli-internal-test-helpers": "^0.9.0",
"eslint-plugin-chai-expect": "^1.1.1",
"eslint-plugin-mocha": "^4.8.0",
"fixturify": "^0.3.4",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should likely take advantage of broccoli-test-helpers which relies on fixturify

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not actually sure which benefits does it offer here. Looks like broccoli-test-helper is intended to be used for testing of the build output diffs which is not related for testing blueprints output I think.

Of course I may miss something because I've never used broccoli-test-helper before... I'd be glad to switch to broccoli-test-helpers if there is some reason.

@ro0gr
Copy link
Copy Markdown
Contributor Author

ro0gr commented Sep 9, 2019

Closing due to current removal of MU blueprints

@ro0gr ro0gr closed this Sep 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants