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)