[TIP] Passing configuration data to Nose tests
kumar.mcmillan at gmail.com
Fri Jul 11 08:39:31 PDT 2008
On Fri, Jul 11, 2008 at 6:53 AM, Jesse Noller <jnoller at gmail.com> wrote:
> I'm trying to decide the best route to pass
> information about the system under test to the tests themselves.
> 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
> 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
> Any thoughts?
This is a common problem and there are ways I'm currently doing it but
I think having a plugin would make things easier. For the most part
I've been using environment variables, documenting them in the
docstring of tests/__init__.py, and sourcing bash scripts to activate
them. I agree that this is not the best approach. As a plugin, I
nosetests --config "dsn:test at localhost/test" --config "gpg_user:foo"
... for quick config overrides. Then:
nosetests --config-file myconfig.ini
... for specifying a custom file. Or, simply add a new section in the
setup.cfg / nose.cfg since this is already a standard place to hold
config data. It might be good to cascade from the setup.cfg to a
custom config (--config-file myconfig.ini) so that the latter could
inherit attributes and override ones it declares. Something like
# nose configuration here ...
dsn = test at localhost/test
gpg_user = foo
use_real_ftp = 1
With that in place, just running `nosetests` on its own should
activate the config plugin and parse the attributes.
Then in the tests themselves:
from nose.plugins.config import testconfig
testconfig would be populated by the plugin's begin() method with
attributes set forth by the config file. It makes sense as a module
global but it might be wise to implement the singleton as a
threadlocal object since work is moving along on parallel testing (see
... uses processing even ;)).
If you or anyone else threw something together like this then I think
it would be a welcome addition to nose's builtin plugins. I know of
people who have implemented their own plugin for this already but they
are one-offs with custom params like --selenium-server=220.127.116.11, not
More information about the testing-in-python