Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package under test not loaded? #5

Open
m-mcgowan opened this issue Aug 10, 2016 · 6 comments
Open

package under test not loaded? #5

m-mcgowan opened this issue Aug 10, 2016 · 6 comments

Comments

@m-mcgowan
Copy link

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.

@ayapi
Copy link
Contributor

ayapi commented Aug 24, 2016

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);

@zmb3
Copy link

zmb3 commented Dec 17, 2017

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

@smhxx
Copy link

smhxx commented Jan 26, 2018

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
Copy link

smhxx commented Jan 26, 2018

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

@BinaryMuse
Copy link
Owner

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).

@t9md
Copy link

t9md commented Mar 15, 2018

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.

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

No branches or pull requests

6 participants