I’m trying to update an old Mirage test that verifies production builds of Mirage strip out nearly all of its files from the build.
Robert mentioned that the current test is brittle because it’s too implementation specific, so I’m trying to rewrite these tests using broccoli-test-helper.
Here’s what I have so far:
it('includes all mirage modules in development', async() => {
let addon = new EmberAddon();
output = createBuilder(addon.toTree());
await output.build();
let files = output.read();
let mirageModulesInBuild = files.assets['vendor.js']
.split('\n')
.filter(line => line.match(";define\\('ember-cli-mirage"));
expect(mirageModulesInBuild.length).to.be.above(1);
});
I hit some roadblocks when I proceeded to write the next test, asserting only 1 file ended up in production builds, because (a) the vendor.js is now fingerprinted and (b) the contents of the file are minified, making it impossible to search for mirage strings.
I’m sure there’s a better way to assert against what files my addon makes available to the host app, but just poking around output I wasn’t able to find anything. Could someone point me in the right direction, or show me some examples from other addons writing these sorts of tests?
I have a similar testing need in ember-auto-import, where I want to make sure some things are available in tests but not in the app.
Normal ember tests don’t work, because in that case you are always testing from inside the test environment, whereas I want to also make assertions about other environments.
My solution was to make a test app (which can be your dummy app) fastboot-compatible, and give it a route that renders the results of checking for the presence of modules in the build. Then in my tests, I can do a real build of whatever environment is needed (literally executing ember build), boot the resulting app in fastboot, and see what HTML comes back for that route.
The test is here, you can execute it via cd test-apps/sample-direct && yarn test:fastboot.
Are there any considerations over maintaining these test apps? I see you use * for the dependencies in their package.json files, which I’m assuming means those will delegate to the parent. But what about file/code changes over time? Would those changes just need to be made when updating the addon? Are there any ideas around higher-level APIs for “given an Ember app with XYZ configuration…”?
That’s a good point. I suppose it would be even cooler to generate them on the fly with ember new so they always reflect current practice. But so far so good. They really don’t have much code in them.
@rwjblue I would be curious to get your take here – I know I’ve written build code in my addons in the past that you disapprove of
Specifically I’m curious about testing & CI. If I make a new ember app in Mirage’s source under test-apps/basic and then use something like Ed’s script to run the acceptance tests for that app as part of my build, is that ok? Do you foresee any issues with it? Is it a good pattern for others to copy?
I’m sure I could brush up my broccoli/ember-cli chops to write the tests using broccoli-test-helper but I’m having a hard time, and there’s something really appealing to me about having an app that I can run with ember s and just develop/debug as a normal Ember app, write components that look at requirejs.entries and write my test assertions using that.
I’ve tried getting my editor’s eslint configured correctly for my test-apps/basic-app folder. I copied your example and re-exported the parent, but it looks like it’s running node 4.5.0. I’m not sure why.
The Travis build is getting stuck on the async line, which also indicates to me Babel is somehow not wired up correctly. It was able to run a basic sync test in my previous build.
Any pointers on which part of the setup I’m missing? Mirage on the latest EmberCLI + other deps but I did update all the babel-related packages I saw, and generally tried to follow your example.
Any help would be appreciated! (You can view the branch here.)
My sample-app’s