PART III¶

How to write good test cases: <link> - Let’s work on an example: $ bzr branch lp:~utah/utah/utah_ls_example - Look at the ts_control file There are both a setup and a cleanup command - Look at ts_util.py sys.path used to import from common module - Look at the common module

STATE_FILE, DATA_FILE defined in terms of the module’s directory

run_cmd used as a method to run a command and get stdout, stderr and returncode.

setup_logging

get_testfiles_data: Used to get the data used by the test cases

Look at data.json: contains filenames and permissions (both in octal number and as string)
Look again at ts_util.py - setup: create directory and files according to the information in the data file

Note: The creation of a tmp directory is something that will be commonly needed and worth having in a library. - Look at permissions/tc_control action and expected results describe what the test does. - Look at permissions.py

sys.path used to import from common

Using unittest module

Look at runTest method

Directory and files exist

Permission string for every file is also correct

Look at dotfiles/tc_control

action and expected results describe what the test does. - Look at dotfiles.py

Directory exists

Dot files are there

Note: We’re not using the unittest runner on purpose. Note: Quite a lot of discussion of whether unittest only for the assertions should be a good practice because it’s confusing. Question: Do you have a skeleton file to encourage users to follow best practice? - Edit master.run - Run Two test case passes Feature request: sudo utah -r . (Run test suite and cases without any master.run file)