duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

Peter Schuller wrote:
> Ok;
> 
> I suggest the following (I've started a bit in my working copy):
> 
> * Change config.py.tmpl to be config.py, and have it
>   execfile('config_loca.py') if it exists. This allows putting your
>   own local configuration in a file which is not going to be a
>   perpertual "must not commit" working copy change, while still not
>   necessitating copying a template file in order to run tests with
>   default settings.

Most of the tests will run without config.py except backendtest.py,
gpg.py, and finalconfig.py.  All of the backend tests have code that
skips them if you do not supply a userid and various keys.

> * Create a tests module (tests.py) which will provide an interface to
>   obtain a list of tests that need and not need root access.

Almost all of the tests need root for SetUp and TearDown due to the
nature of the testfiles directory (mix of UIDs, permissions, etc.).
Pretty much any of them that run SetUp need root.

> * Create a base class for tests that need the 'testfiles' unapcked, which
>   will do so as part of setUp() and remove it as part of tearDown() (unless
>   some smart optimization is used this would mean redundant tarring
>   multiple times though). They would do this setup/teardown by assuming sudo
>   access, like the current shell scripts do.

I intentionally have SetUp and TearDown in each test that needs them so
I can run them in isolation and debug them with Eclipse/PyDev Unittest.
 While running all of the tests, the data stays in cache, so there's not
much real overhead.  Most tests finish before the system bothers to
actually write it to disk.

> * Extend each base class as appropriate.
> 
> * Provide convenience runners (testing/all_tests.py,
>   testing/indep_tests.py etc) for running all tests in a certain
>   category or all tests period.

Not sure about categories of tests, but the shell scripts are no longer
needed for the individual tests.  If we ran categories of tests, they
would run much like run_all_tests, just with a different list.

> The tests module would either not contain a list at all (and discovery
> *_test.py files) or contain the "all tests" list and dynamically
> discover which tests require root and which don't (by inspecting their
> inheritance).
> 
> * I am also considering whether to put the tests in a duplicit.testing
>   package in order to make the coupling to local files less strict and
>   place it firmly inside duplicity to avoid clashes in some
>   situations. The testing/ directory would then only contain runnable
>   scripts, with the bulk of actual tests in duplicity/testing/*.py.

Not sure I would want to move them under duplicity itself.  Coupling to
the local files is a valid assumption during testing since you would
want to know that the files you're testing are the ones in your dev
directory, not the ones in the system path.  Besides, some of the files
test duplicity-bin itself, so you're coupled anyway.

> Thoughts?

All this sounds good.  If you have time to do this, go ahead.

...Ken