> 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.
Yeah I noticed they did, though it also means they do not test everything. > > * 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. I tried them out and got a fair few that were actually okay without it. > > * 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. Ah, I was actually commenting on the performance in the sense of a would-be regression, as I hadn't noticed the setup/teardown doignn that already (I thought the wrapper script was the day to do it). Guess I'll have to look more carefully :) > 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. Ok. > 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. True. > > Thoughts? > > All this sounds good. If you have time to do this, go ahead. Will see; I kinda dropped the ball on this; it's sitting partially started in my working copy still... -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[email protected]>' Key retrieval: Send an E-Mail to [email protected] E-Mail: [email protected] Web: http://www.scode.org
pgpHsN9EcTNmi.pgp
Description: PGP signature
_______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
