Ability to set arguments for a test

[Michael Nelson]

...without complicating invocation. Things like optionally setting the base_url for the tests (which would override some default), or an IMAP password etc.

{{{
13:31 < noodles> mfoord: do you know if there'll be support for optional arguments with sst? (setting the base_u
rl or gmail password from the command-line come to mind)
13:36 < mfoord> noodles: there will be whatever we add
13:37 < mfoord> noodles: I know that doesn't specifically answer your question...
13:37 < noodles> mfoord: yeah, I'd be happy to go in and try to add it (when it's a priority), I just wasn't sur
e if there were already plans from you or cory.
13:37 < mfoord> noodles: we must use this opportunity to make sst more capable though - instead of just writing
very hacky tests that work around its deficiencies
13:37 < mfoord> noodles: what could be useful is a way to pass command line args through to the scripts
13:38 < mfoord> noodles: maybe ./sst-run -x:opt1=thing -X:opt2=thing
13:38 < mfoord> noodles: and any option prefixed with an x: is put into a global array that scripts can read
13:39 < mfoord> noodles: and then a utility function in the script can read those options and act appropriately
13:39 < mfoord> noodles: for sst itself we want something generally useful rather than just stuff for our specif
ic tests
13:40 < mfoord> noodles: I don't know how easy that is to do with argparse though which expects to recognise all
 the options...
13:40 < noodles> mfoord: what about just using env vars (too hacky?)
13:40 < mfoord> noodles: that would work, but not very easy to use
13:42 < noodles> GMAIL_PASSWORD=foo ./sst-run ..., vs, ./sst-run -x:GMAIL_PASSWORD=foo, yeah, I think that's a d
ecision for cgoldberg.
}}}

[David Owen (dsowen)]

Perhaps we could include "profiles". Each profile would be described entirely in its own file. The user would only need to specify which profile to test against, and a default could be used.

[Michael Foord (mfoord)]

How would we include profiles - what would they be?

It seems like you could implement profiles yourself with command line argument support, but for us to provide profiles it would need command line support. So just providing command line argument support seems like a win...

[Michael Foord (mfoord)]

Using environment variables requires no particular support from sst - you could use those already if you wanted - so the only reason to add command line handling is if it is a nicer "ui" for users. I think it is.

[Michael Nelson (michael.nelson)]

On Wed, Jul 27, 2011 at 5:13 PM, Michael Foord
<email address hidden> wrote:
> Using environment variables requires no particular support from sst -
> you could use those already if you wanted - so the only reason to add
> command line handling is if it is a nicer "ui" for users. I think it is.

True! I'll update the new account tests to have a default (staging)
but allow overriding with an env var. If that solves my use-case (as
we shouldn't have too many of these I think, and they should be
standard across all tests in a test run right?). So far I've only
found GMAIL_PASSWORD and BASE_URL.

@dsowen: using simple env vars would even enable you to define
profiles very easily:
$ source staging_profile

or
$ ./set_staging_profile
or whatever?

[Guiohm (guiohm)]

Hi, I'm about to use this framework at my company. We use Saucelabs, and some args (other than the WEBDRIVER_REMOTE_URL) are missing.
So I'm about to adapt this to our needs. I would rather try to make it the more generic possible so that it can be merged upstream. It's why I post here.

Using custom args sounds a good solution.
I'll probably need also to add a sort of Saucelabs driver to communicate the test results back to them and be able to use their interface for the reports. Will this kind of change be accepted? Or should I just limit myself to submit custom args support changes and keep Saucelabs specifics on my branch?

Thanks.
(Saucelabs stuff probably deserve a dedicated topic)