User's Guide
Reference Manual
Release Notes
PDF
Top

Common Test
User's Guide
Version 1.8

Expand All
Contract All

Chapters

• Common Test Basics
  • Top of chapter
  • Introduction
  • Test Suite Organisation
  • Support Libraries
  • Suites and Test Cases
  • External Interfaces
• Getting Started
  • Top of chapter
  • Are you new around here?
  • Test case execution
  • A simple test suite
  • A test suite with configuration functions
  • What happens next?
• Installation
  • Top of chapter
  • General information
• Writing Test Suites
  • Top of chapter
  • Support for test suite authors
  • Test suites
  • Init and end per suite
  • Init and end per test case
  • Test cases
  • Test case info function
  • Test suite info function
  • Test case groups
  • The parallel property and nested groups
  • Parallel test cases and IO
  • Repeated groups
  • Shuffled test case order
  • Group info function
  • Info functions for init- and end-configuration
  • Data and Private Directories
  • Execution environment
  • Timetrap timeouts
  • Logging - categories and verbosity levels
  • Illegal dependencies
• Test Structure
  • Top of chapter
  • Test structure
  • Skipping test cases
  • Definition of terms
• Examples and Templates
  • Top of chapter
  • Test suite example
  • Test suite templates
• Running Tests and Analyzing Results
  • Top of chapter
  • Using the Common Test Framework
  • Automatic compilation of test suites and help modules
  • Running tests from the OS command line
  • Running tests from the Erlang shell or from an Erlang program
  • Test case group execution
  • Running the interactive shell mode
  • Step by step execution of test cases with the Erlang Debugger
  • Test Specifications
  • Running tests from the Web based GUI
  • Log files
  • HTML Style Sheets
  • Repeating tests
  • Silent Connections
• External Configuration Data
  • Top of chapter
  • General
  • Syntax
  • Requiring and reading configuration data
  • Using configuration variables defined in multiple files
  • Encrypted configuration files
  • Opening connections by using configuration data
  • User specific configuration data formats
  • Examples of configuration data handling
  • Example of user specific configuration handler
• Code Coverage Analysis
  • Top of chapter
  • General
  • Usage
  • Stopping the cover tool when tests are completed
  • The cover specification file
  • Cross cover analysis
  • Logging
• Using Common Test for Large Scale Testing
  • Top of chapter
  • General
  • Usage
  • Test Specifications
  • Automatic startup of test target nodes
• Event Handling
  • Top of chapter
  • General
  • Usage
• Dependencies between Test Cases and Suites
  • Top of chapter
  • General
  • Saving configuration data
  • Sequences
• Common Test Hooks
  • Top of chapter
  • General
  • Installing a CTH
  • CTH Scope
  • Manipulating tests
  • Synchronizing external user applications with Common Test
  • Example CTH
  • Built-in CTHs
• Some thoughts about testing
  • Top of chapter
  • Goals
  • What to test?

14 Some thoughts about testing

14.1  Goals

It's not possible to prove that a program is correct by testing. On the contrary, it has been formally proven that it is impossible to prove programs in general by testing. Theoretical program proofs or plain examination of code may be viable options for those that wish to certify that a program is correct. The test server, as it is based on testing, cannot be used for certification. Its intended use is instead to (cost effectively) find bugs. A successful test suite is one that reveals a bug. If a test suite results in Ok, then we know very little that we didn't know before.

14.2  What to test?

There are many kinds of test suites. Some concentrate on calling every function or command (in the documented way) in a certain interface. Some other do the same, but uses all kinds of illegal parameters, and verifies that the server stays alive and rejects the requests with reasonable error codes. Some test suites simulate an application (typically consisting of a few modules of an application), some try to do tricky requests in general, some test suites even test internal functions with help of special load-modules on target.

Another interesting category of test suites are the ones that check that fixed bugs don't reoccur. When a bugfix is introduced, a test case that checks for that specific bug should be written and submitted to the affected test suite(s).

Aim for finding bugs. Write whatever test that has the highest probability of finding a bug, now or in the future. Concentrate more on the critical parts. Bugs in critical subsystems are a lot more expensive than others.

Aim for functionality testing rather than implementation details. Implementation details change quite often, and the test suites should be long lived. Often implementation details differ on different platforms and versions. If implementation details have to be tested, try to factor them out into separate test cases. Later on these test cases may be rewritten, or just skipped.

Also, aim for testing everything once, no less, no more. It's not effective having every test case fail just because one function in the interface changed.