| | 1 | = Bitten Data Storage = |
| | 2 | |
| | 3 | The data generated by automated builds can almost always be mapped to the physical and/or the logical view of the code base, where the physical view corresponds to files and line numbers, while the logical view is composed of units such as packages, classes and functions. Specific metrics basically annotate either view with the extracted information. The structure of the annotation, however, depends entirely on the type of metric. |
| | 4 | |
| | 5 | For example, test results might have the following attributes: |
| | 6 | |
| | 7 | * Name of the test |
| | 8 | * Result: success, failure or error |
| | 9 | * Error message and stack trace (in case of an error or failure) |
| | 10 | * Output of the test (standard error and output streams) |
| | 11 | * Time it took to execute the test |
| | 12 | |
| | 13 | Other data such as compilation errors and warnings would only consist of the message of the error or warning. Code coverage would annotate each line in the code base with the number of times that line has been executed, and in addition accumulate coverage statistics on a per-file or per-class basis. |
