Document coding standards for automated tests

Originally reported by Rohan McGovern as QT-2455

Conforming to a set of coding standards will make it more likely for autotests to work reliably in all environments.

For example, some Qt autotests need to read data from disk. In the past there have been no standards set for how this is done, therefore many tests have made various assumptions such as the testdata always being present in the current working directory, or the tests being build in-source rather than a shadow build. This makes those tests less portable.

This is one aspect of tests which could benefit from coding standards. Other aspects should be investigated and relevant coding standards written.

At time of writing, points which come to mind are:

• accessing on-disk testdata
• naming of testcases (important because, if a testcase fails to generate valid output, its name should still be deducible so its failure can be reported)
• verifying that preconditions are true (e.g. a bluetooth test gracefully skipping if bluez is not available locally)
• accessing settings which may be machine-specific or need to be private (e.g. database access details for SQL tests)

As a part of this task, it might be determined that additional APIs are needed in the test framework, in which case the coding standard might boil down to "If you need to do task X, use API Y".