Writing Python Tests
- 1 Writing Python Tests for Samba
- 2 Good Patterns
Writing Python Tests for Samba
Python unittest.TestCase is the standard basis on which all of Samba's python based tests should be written.
This provides helpful routines such as assertTrue() etc, which provide a cosnsitent pattern in the tests.
Samba's subclass samba.tests.TestCase, provides additional helper routines such as env_loadparm()
You can explore the methods provided using pydoc:
PYTHONPATH=bin/python pydoc samba.tests.TestCase
Testing Samba binaries
When testing Samba binaries, please use:
Obtaining credentials for a sub process
A pattern like this is typical for passing credentials to a subprocess
creds = self.get_credentials() cmd_line_auth = "-U%s/%s%%%s" % (creds.get_domain(), creds.get_username(), creds.get_password())
Running the subprocess
Use self.check_run or self.check_output
self.check_run("ndrdump samr samr_CreateUser in %s" % (self.data_path("samr-CreateUser-in.dat")))
samba-tool is a special case, as it is written in python. To avoid a fork()/exec() of python from python, use
The runcmd() and runsubcmd() methods allows testing of a samba-tool command in the same process, which also allows the use of
This example from source4/torture/drs/python/fsmo.py shows how to run an authenticated subcommand without forcing a new kinit:
ccache_name = self.get_creds_ccache_name() cmd_line_auth = "--krb5-ccache=%s" % ccache_name (result, out, err) = self.runsubcmd("fsmo", "transfer", "--role=%s" % role, "-H", "ldap://%s:389" % DC, cmd_line_auth)
If you need a temp dir, use
descend from this class, so the self.tempdir attribute is available with a temporary directory. The framework will assert that directory is empty when the test is done.
Where to add new tests
Samba Tests are scattered around the code. However, in general, unless already related to or derived from other tests, new tests should be added in
Tests should be run using subunitrun if possible, declared in tests.py via planpythontestsuite(), not planoldpythontestsuite()
Try not to make your new test special. The more our tests look like each other, the easier it is for new developers to follow the same patterns.