[TIP] Passing configuration data to Nose tests

[Jesse Noller]

Again - another one of those "I could go off and just do this, but I
thought seeing what other people were doing made more sense" type of
posts.

So, I'm proceeding with using nose as a local test executor for
everything from unit to larger-scale functional tests. The latter of
which is the "problem" - I'm trying to decide the best route to pass
information about the system under test to the tests themselves.
There's a few approaches I've considered - environment variables
(which don't scale, clutter the code, etc) and using some
configuration file mechanism.

For configuration files - ideally I'd be able to run something like
"nostests --with-test-config <foo.config>" and nose would pass in the
configuration file already parsed and turned into a "real" object
instead of leaving parsing to the tests themselves. For the actual
format of the configuration file - well, that one is another handful
of choices: YAML - which would allow me to write the data in something
human readable, but also do advanced things like construct object
directly during parsing, have type settings, etc. XML - which is not
human readable at a certain point (and doesn't have the object
features of YAML), or a flat text file (which while human readable -
doesn't scale, have type coercion, have to write a parser, etc) or
finally, a ConfigObj style configuration file.

I could handle this in the test package's setup_function in
__init__.py - but I think having a plugin to manage what's passed to
the test makes more sense rather than hardcoding/poking around the
filesystem for configuration files in the __init__.py file.

So, I'm wondering if anyone else has dealt/thought about this - the
configuration data is quick-to-change, so having a pile of
configuration files "around" doesn't make sense - they're going to be
auto generated by some other agent. It also doesn't make sense to add
the information to the nose configuration file itself for this very
reason.

The data itself looks something like:

HOST_IP = <>
PROD_VER = <>
HOST_SIZE = <>

And so on - given these are functional black-box tests, they have to
have a fair amount of data describing where, what and how to run the
tests.

Any thoughts?

-jesse