Add a tutorial for non Sauce users

[gaurav21r]

Hey! I'm a long term contributor to Dojo. It's good to know it now uses Sauce Labs and theintern for testing.

I think I speak for a lot of people when I say that not all of us may have Open Source Projects or could afford Sauce Labs pricing. If we truly believe TheIntern should become a widespread testing framework, I think a tutorial on running functional tests using Selenium should also be added.

Here's a question from Bill Keese. Can we convert the answer into a tutorial? http://stackoverflow.com/questions/16414829/how-do-i-setup-selenium-2-server-so-intern-can-run-functional-tests-locally-on

[jason0x43]

I agree, that would be nice to have. More information on running the tests with a local Webdriver server could be added to the Step 5 section, or maybe as a Step 5b or something.

[neonstalwart]

@gaurav21r i put together a gist of how to run the intern tests locally... it shows how simple it is to setup selenium on a local machine https://gist.github.com/neonstalwart/6630466. it's no substitute for docs but it adds some code to support the response i gave to bill on SO.

actually... i just noticed that i already linked to that gist in an edit on that post 😃

[bitmage]

I have been using this set of scripts to run Selenium locally:

https://github.com/sebv/sv-selenium

npm install -g sv-selenium
install_selenium
install_chromedriver
start_selenium_with_chromedriver

I found this project as a dev dependency of 'wd'. Not very robust, but it'll get you running and it's easy. neonstalwart's approach looks better for a more flexible approach.

Once you have Selenium running locally:

1. point your config to it (the webdriver property)
2. turn "useSauceConnect" to false
3. set "capabilities" to whatever Selenium version you're running (the project linked above puts you on 2.35.0)
4. update the environments section for browsers your local selenium actually supports. I used {browserName: 'chrome'}

Now clearly your local config is going to differ from the one you use with Sauce Labs. I'm still wondering what the recommended approach would be for someone like me who'e intending to run locally and then use Sauce for CI. My guess is you'll have to figure that out with whatever build system you happen to use.

[neonstalwart]

Now clearly your local config is going to differ from the one you use with Sauce Labs. I'm still wondering what the recommended approach would be for someone like me who'e intending to run locally and then use Sauce for CI. My guess is you'll have to figure that out with whatever build system you happen to use.

since the configs are just AMD modules, they can depend on other modules. so, i'd be inclined to keep a hierarchy of configs.

// intern.base.js
define({
    // The port on which the instrumenting proxy will listen
    proxyPort: 9000,

    // A fully qualified URL to the Intern proxy
    proxyUrl: 'http://localhost:9000/',

    // Default desired capabilities for all environments. Individual capabilities can be overridden by any of the
    // specified browser environments in the `environments` array below as well. See
    // https://code.google.com/p/selenium/wiki/DesiredCapabilities for standard Selenium capabilities and
    // https://saucelabs.com/docs/additional-config#desired-capabilities for Sauce Labs capabilities.
    // Note that the `build` capability will be filled in with the current commit ID from the Travis CI environment
    // automatically
    capabilities: {
        'selenium-version': '2.37.0',
        'idle-timeout': 30
    },

    // Browsers to run integration testing against. Note that version numbers must be strings if used with Sauce
    // OnDemand. Options that will be permutated are browserName, version, platform, and platformVersion; any other
    // capabilities options specified for an environment will be copied as-is
    environments: [
        { browserName: 'internet explorer', version: '11', platform: 'Windows 8.1' },
        { browserName: 'internet explorer', version: '10', platform: 'Windows 8' },
        { browserName: 'internet explorer', version: '9', platform: 'Windows 7' },
        { browserName: 'firefox', version: '25', platform: [ 'OS X 10.6', 'Windows 7', 'Linux' ] },
        { browserName: 'chrome', version: '31', platform: 'Windows 7' },
        { browserName: 'chrome', version: '30', platform: 'Linux' },
        { browserName: 'chrome', version: '27', platform: 'OS X 10.8' },
        { browserName: 'safari', version: '6', platform: 'OS X 10.8' }
    ],

    // Maximum number of simultaneous integration tests that should be executed on the remote WebDriver service
    maxConcurrency: 3,

    // Whether or not to start Sauce Connect before running tests
    useSauceConnect: false,

    // Connection information for the remote WebDriver service. If using Sauce Labs, keep your username and password
    // in the SAUCE_USERNAME and SAUCE_ACCESS_KEY environment variables unless you are sure you will NEVER be
    // publishing this configuration file somewhere
    webdriver: {
        host: 'localhost',
        port: 4444
    },

    // Configuration options for the module loader; any AMD configuration options supported by the Dojo loader can be
    // used here
    loader: {
        // Packages that should be registered with the loader in each testing environment
        packages: [ { name: 'intern-selftest', location: '.' } ],
        map: { 'intern-selftest': { dojo: 'intern-selftest/node_modules/dojo' } }
    },

    // Non-functional test suite(s) to run in each browser
    suites: [ 'intern-selftest/tests/all' ],

    // Functional test suite(s) to run in each browser once non-functional tests are completed
    functionalSuites: [ 'intern-selftest/tests/functional/basic' ],

    // A regular expression matching URLs to files that should not be included in code coverage analysis
    excludeInstrumentation: /^(?:tests|node_modules)\//
});


// intern.sauce.js
define([ './intern.base' ], function (baseConfig) {
    baseConfig.useSauceConnect = true;

    return baseConfig;
});

// intern.local.js
define([ './intern.base' ], function (baseConfig) {
    baseConfig.capabilities['selenium-version'] = '2.35.0';

    baseConfig.environments = [
        { browserName: 'firefox' },
        { browserName: 'safari' },
        { browserName: 'chrome' }
    ];

    return baseConfig;
});

then you would just invoke intern with whichever config you needed. since there's really only 2 environments in this example, you might just make your default/base config be configured for sauce and then have the local one import that and make the necessary adjustments rather than have 3 configs.

NOTE: i should mention that i've been meaning to confirm that this approach actually works but haven't got around to trying it yet. i don't expect there would be any issues though. it works as expected

[bitmage]

Yeah, that makes sense. I don't see any reason it wouldn't work either, it's just standard AMD.

[wayneseymour]

I use webdriver-manager and/or appium (for iOS simulator testing) to start my selenium srvr locally.
webdriver-manager is an executable that comes with angular protractor: on github

[DavidSpriggs]

An update to the above:

$ brew update
$ brew doctor
$ brew install selenium-server-standalone chromedriver

To run selenium:

$ java -jar /usr/local/opt/selenium-server-standalone/libexec/selenium-server-standalone-2.40.0.jar -p 4444

Then to run your tests:

$ node node_modules/intern/runner.js config=tests/intern.js

[lfender6445]

even with all of these config options, i am still getting attempts to connect to saucelabs instead of local selenium instance https://gist.github.com/lfender6445/9c6c5d31666c46799eee - any ideas?

[neonstalwart]

change your tunnel - read about the NullTunnel on this page https://github.com/theintern/intern/wiki/Configuring-Intern

[gaurav21r]

Good work on this thread. Why don't we add it to the main Docs?

[csnover]

Information in today’s user guide should be able to address questions about how to set up other kinds of servers or use other cloud hosting providers, so I will close this ticket.