setting-up-intern.md

set up sauce labs/browserstack account (remote tests)
download selenium server (not selenium IDE) & install Java (for local tests)
install phantomjs (brew install phantomjs) (probably doesn't work with intern-geezer)
to structure a directory: git clone https://github.com/theintern/intern-tutorial
- we don't care about the application, so you can
  - rm -r app
  - rm index.html
step through steps 1 and 2 of the intern tutorial
- but! don't install the main intern package on npm. you'll use npm install intern-geezer --save-dev. the geezer branch is capable of driving
- you also don't need to worry about changing the packages attribute in loader (that's for dealing with the local app)
- You may want to actually read the entire tutorial; it has some helpful information.
You can skip step 3. I think we'd rather use qUnit for unit tests.
put https://gist.github.com/mambocab/b915c26844e07870aaa1 in tests/functional, and name it tests.js.
go into tests/intern.js and change the functionalSuites list to contain the string 'myPackage/tests/functional/tests'.
explanation: note that we loaded our local files in the loader.packages attribute as myPackage. (In real testing, we could use that to load the pages we want to test.) So, since . is myPackage, that means our test file is the 'package' myPackage/tests/functional/tests.

local tests

in tests/intern.js, do the following:
change the tunnel attribute to ’NullTunnel’
comment out all the objects in the environments attribute, and add the object { browserName: 'safari'}.
open a new tmux window, because we're gonna start a server! then java -jar ${PATH_TO_SELENIUM_SERVER_EXECUTABLE}.
that'll start up a selenium server listening on port 4444. (for debugging later, you can check to see if it's still on that port with lsof -i :4444)
now you should be ready to run your tests locally with ./node_modules/.bin/intern-runner config=tests/intern. It’ll start up an instance of Safari and run the tests!
If it doesn’t, then you got problems.

You need to put your Sauce authentication information somewhere where Intern can get it -- you can put that in your config file, but I think that’s a bad idea, since you might commit it to source control. I leave it as an exercise to the reader, if the reader is smarter than me and will never commit their access key. I recommend exporting them as environment variables in the shell where you will launch the tests:
export SAUCE_USERNAME=xxxx
export SAUCE_ACCESS_KEY=xxxx (get your access key from the left sidebar on the sauce labs dashboard.)
Then go back into intern.js.
Get rid of the { browserName: 'safari'} object and uncomment one of the other objects in environments - this will specify the browser and platform you want to run the tests on.
change the tunnel to NullTunnel (or just comment that line out -- NullTunnel is the default
aaaand you should be good to run your tests on Sauce Labs’ cloud: ./node_modules/.bin/intern-runner config=tests/intern.