Files
meteor/tools/tests/deploy-settings.js
ekatek ef13ed9926 use selftest to run tests against galaxy
UX Changes:
  - Added a `--galaxy` option to selftest to run tests against galaxy.
    Self-test will NOT run those tests without this option. Self-test will not run any
    other tests WITH this option.

    The motivation here is two-fold:
     - We want to make it easy to use self-test to test Galaxy without running a bunch
       of extra tests. At least, we want this right now, while Galaxy is still in development.

     - Galaxy is currently pretty unstable&slow; we don't want to run our regular test suite against
       Galaxy all the time and slow down the tool development process. Additionally, the environment
       variables required by Galaxy are a pain to set.

    This is a TEMPORARY situation. Eventually, we will want to either merge the two tests together
    (especially once we rotate out Mother...) or we will have a separate unrelated Galaxy test suite
    and move a lot of this stuff here. With time, it will also become more obvious what a better default
    (run Galaxy tests always/run Galaxy tests never/run non-Galaxy-specific tests against Galaxy) is.

    The changes should be pretty self-contained.

 - Added some number of environment variables to use with --galaxy tests. This is a bit complicated
   and will be documented in
     https://mdg.hackpad.com/GalaxyECS-Admin-tasks-RTXJ5YW8pDv#:h=Testing-Galaxy-with-selftest.

Walkthrough:
    - galaxy-utls.js contains basic utils for running Galaxy tests. Use environment variables, etc.

    - galaxy.js contains the acutal test

    - simple-app is an app that responds to HTTP requests and serves some html that we can test to be running

    - minor changes to config.js to allow overriding of the domain name

    - minor changes to auth.js to allow us to automatically login as the (new) test user and use that
      login to start a DDP collection.

    - move a function out of deploy-settings.js into test-utils.js

    - some minor additions to test-utils.js

Reviewed in https://github.com/meteor/meteor/pull/4997.
2015-08-26 19:06:13 -07:00

56 lines
2.0 KiB
JavaScript

var selftest = require('../tool-testing/selftest.js');
var testUtils = require('../tool-testing/test-utils.js');
var utils = require('../utils/utils.js');
var Sandbox = selftest.Sandbox;
selftest.define('deploy - with settings', ['net', 'slow'], function () {
var s = new Sandbox;
testUtils.login(s, 'test', 'testtest');
var settings = {
'public': { a: 'b' }
};
s.write('settings.json', JSON.stringify(settings));
// Deploy an app with settings and check that the public settings
// appear in the HTTP response body.
var appName = testUtils.createAndDeployApp(s, {
// Use standard-app instead of empty because we actually want
// standard-app-packages (including webapp) so that we can send a
// HTTP request to the app and get a response.
templateApp: 'standard-app',
// The path is ../settings.json instead of settings.json because
// createAndDeployApp creates a new app directory and cd's into it.
settingsFile: '../settings.json'
});
testUtils.checkForSettings(appName, settings, 10);
// Re-deploy without settings and check that the settings still
// appear.
s.cd('..');
testUtils.createAndDeployApp(s, {
templateApp: 'standard-app',
appName: appName
});
// It takes a few seconds for the app to actually update, and we don't
// want to get a false positive in the meantime (i.e., if the settings
// disappear, we don't want to send our request before the app has
// updated and conclude that the settings are still there).
utils.sleepMs(5000);
testUtils.checkForSettings(appName, settings, 10);
// Re-deploy with new settings and check that the settings get
// updated.
settings['public'].a = 'c';
s.cd('..');
s.write('settings.json', JSON.stringify(settings));
testUtils.createAndDeployApp(s, {
templateApp: 'standard-app',
settingsFile: '../settings.json',
appName: appName
});
testUtils.checkForSettings(appName, settings, 10);
testUtils.cleanUpApp(s, appName);
testUtils.logout(s);
});