atom-mocha-test-runner icon indicating copy to clipboard operation
atom-mocha-test-runner copied to clipboard

package under test not loaded?

Open m-mcgowan opened this issue 9 years ago • 6 comments

I started a new es6 atom package using jasmine, which contained code like:

    it('can be loaded', () => {
        waitsForPromise(() => atom.packages.activatePackage(packageName()));
    });

And this worked as expected - the package was activated. However, similar code under the mocha runner doesn't work out the box.

    it('can be loaded', () => {
        return atom.packages.activatePackage(packageName());
    });

Looking through the mocha runner code, I found that the config directory is set to a temporary directory by default, so the package isn't present in the atom environment. Is there a good way to have the package under test loaded?

What I did was to use apm link to ensure the package was installed in the global packages directory, and then added

    beforeEach(() => {
        global.atom = global.buildAtomEnvironment({configDirPath: process.env.ATOM_HOME});
    });

Which uses the global config directory - as used by the jasmine runner - so that the atom instance was configured using the global config. It's not ideal since the test environment is no longer clean, but it worked for local development.

The next hurdle was then getting the travis-ci build to run. It seems there was no way to have apm link run to have the package linked to the global atom config. I'm stuck here....and since it feels like I'm running uphill, against the grain, that might be a sign I'm on the wrong track and there's a simpler approach!

Not sure if this is a bug, my misunderstanding or missing features, so just putting what I know here in case someone knows the way forward.

m-mcgowan avatar Aug 10 '16 19:08 m-mcgowan

i faced with the same problem, for what it’s worth, the following are my solution.

(mypackage-dir)/test-runner.js

const fs = require('fs-plus');
const path = require('path');
const createRunner = require('atom-mocha-test-runner').createRunner;
const extraOptions = {
  globalAtom: true
};

function optionalConfigurationFunction(mocha) {
  let packageName = require('./package.json').name;
  let packagesDir = atom.packages.getPackageDirPaths().find((path) => {
    return path.endsWith('/dev/packages');
  });
  fs.makeTreeSync(packagesDir);
  try {
    fs.symlinkSync(__dirname, path.join(packagesDir, packageName), 'junction');
  } catch (err) {
    console.log(err);
  }
}

module.exports = createRunner(extraOptions, optionalConfigurationFunction);

ayapi avatar Aug 24 '16 11:08 ayapi

Also stuck here 🤔 I'm not sure how https://github.com/atom/github gets around this.

zmb3 avatar Dec 17 '17 21:12 zmb3

atom/github "gets around it" by never attempting to activate itself in its tests, the only package it activates is language-git. (I'm guessing that makes a difference... somehow?) I haven't been able to find any package using atom-mocha-test-runner that actually successfully activates itself during testing. I've created a repro package to demonstrate the bug at smhxx/atom-mocha-bug-repro.

Steps to reproduce: Clone smhxx/atom-mocha-bug-repro. Run npm install to fetch dependencies, then apm link. Open the project in atom and use Ctrl+Shift+Y to start the test runner.

Expected behavior: The package is successfully activated and all tests pass.

Actual behavior: The test times out, and the following is output to the console:

⚠️ Could not resolve 'example-package' to a package path
❌ Uncaught (in promise) Error: Failed to load package 'example-package'
    at PackageManager.activatePackage (<...>\AppData\Local\atom\app-1.24.0-beta3\resources\app.asar\src\package-manager.js:713:29)
    at Context.<anonymous> (<...>\example-package\spec\example-package.test.js:6:19)
    at callFnAsync (<...>\example-package\node_modules\mocha\lib\runnable.js:371:21)
    at Test.Runnable.run (<...>\example-package\node_modules\mocha\lib\runnable.js:318:7)
    at Runner.runTest (<...>\example-package\node_modules\mocha\lib\runner.js:443:10)
    at <...>\example-package\node_modules\mocha\lib\runner.js:549:12
    at next (<...>\example-package\node_modules\mocha\lib\runner.js:361:14)
    at <...>\example-package\node_modules\mocha\lib\runner.js:371:7
    at next (<...>\example-package\node_modules\mocha\lib\runner.js:295:14)
    at Immediate.<anonymous> (<...>\example-package\node_modules\mocha\lib\runner.js:339:5)
    at runCallback (timers.js:651:20)
    at tryOnImmediate (timers.js:624:5)
    at processImmediate [as _immediateCallback] (timers.js:596:5)

smhxx avatar Jan 26 '18 03:01 smhxx

For the record, @ayapi's workaround works great. Perhaps a potential solution is simply to have atom-mocha-test-runner do this automatically?

smhxx avatar Jan 26 '18 04:01 smhxx

Sorry it's taken me so long to get back to this issue. The atom-mocha-test-runner was designed to do way less automatic stuff when testing; the default Atom test runner mocks timers, creates Atom environments, and activates packages under test, which we wanted to avoid and make more explicit long term.

That said, I definitely understand that this can be a surprising difference when migrating from the built-in runner, and the larger changes we wanted to make to the test process for Atom packages haven't been built yet, so I'm open to adding an option to activate the current project directory as an Atom package (assuming globalAtom is also on).

BinaryMuse avatar Jan 30 '18 22:01 BinaryMuse

Sharing my experience when I migrated my atom-narrow pkg to use this test-runner. Here is my runner.js. Still some view related test fail only when I execute spec by window:run-package-specs, so I sent #13.

t9md avatar Mar 15 '18 03:03 t9md