Test Function List Sample: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Introduction == | == Introduction == | ||
Function Lists are abbreviated as ' | Function Lists are abbreviated as ''flist'' in both pragmas (as in [[scl_test_flist]]) and documentation. The Test flist Samples pertain to test units that contain lists of functions to be executed. The Test FList functionality is intended as a simple grouping of test functions. It requires that all functions have c-linkage (extern "C") and does not support more advanced usages patterns like private test data. If you need more advanced functionality, consider using [[Test Class Samples|Test Classes (c++)]] or [[Test CCLass Samples|Test C-Classes]] and designed to be used with the C language (although it is not restricted from compilation in a C++ environment as well). | ||
== Tests Description == | == Tests Description == | ||
| Line 8: | Line 8: | ||
These examples cover the simplest, easiest way to code STRIDE scl_test_flist functionality. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments). | These examples cover the simplest, easiest way to code STRIDE scl_test_flist functionality. These examples use simple [http://en.wikipedia.org/wiki/Plain_Old_Data_Structures POD] return types to indicate status and do not annotate the tests with any rich information (such as comments). | ||
==== | ==== basic_simple ==== | ||
This example demonstrates passing and failing tests using the primary POD types that infer status from (int, bool, short, and char). The bool type is only accepted in C++ mode. | This example demonstrates passing and failing tests using the primary POD types that infer status from (int, bool, short, and char). The bool type is only accepted in C++ mode. | ||
==== | ==== basic_fixtures ==== | ||
This example shows how to use [[Test_Units#Pragmas_for_Test_Units|setup]] and [[Test_Units#Pragmas_for_Test_Units|teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively. | This example shows how to use [[Test_Units#Pragmas_for_Test_Units|setup]] and [[Test_Units#Pragmas_for_Test_Units|teardown]] fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively. | ||
| Line 17: | Line 17: | ||
These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h). | These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h). | ||
==== | ==== runtimeservices_simple ==== | ||
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information. | This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to set status, [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]] to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information. | ||
==== | ==== runtimeservices_dynamic ==== | ||
This example shows how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddCase|srTestSuiteAddCase]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method. | This example shows how to use [[Test_Units#srTestSuiteAddSuite|srTestSuiteAddSuite]], [[Test_Units#srTestSuiteAddCase|srTestSuiteAddCase]], [[Test_Units#srTestSuiteAddAnnotation|srTestSuiteAddAnnotation]], and [[Test_Units#srTestAnnotationAddComment|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method. | ||
==== | ==== runtimeservices_override ==== | ||
This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value. | This example shows how to use [[Test_Units#srTestCaseSetStatus|srTestCaseSetStatus]] to override the status that would otherwise be inferred from the return value. | ||
==== | ==== runtimeservices_varcomment ==== | ||
This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]]. | This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Test_Units#srTestCaseAddComment|srTestCaseAddComment]]. | ||
[[Category: Samples]] | [[Category: Samples]] | ||
Revision as of 17:03, 4 June 2009
Introduction
Function Lists are abbreviated as flist in both pragmas (as in scl_test_flist) and documentation. The Test flist Samples pertain to test units that contain lists of functions to be executed. The Test FList functionality is intended as a simple grouping of test functions. It requires that all functions have c-linkage (extern "C") and does not support more advanced usages patterns like private test data. If you need more advanced functionality, consider using Test Classes (c++) or Test C-Classes and designed to be used with the C language (although it is not restricted from compilation in a C++ environment as well).
Tests Description
Basic
These examples cover the simplest, easiest way to code STRIDE scl_test_flist functionality. These examples use simple POD return types to indicate status and do not annotate the tests with any rich information (such as comments).
basic_simple
This example demonstrates passing and failing tests using the primary POD types that infer status from (int, bool, short, and char). The bool type is only accepted in C++ mode.
basic_fixtures
This example shows how to use setup and teardown fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.
Runtime Services
These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h).
runtimeservices_simple
This example shows how to use srTestCaseSetStatus to set status, srTestCaseAddComment to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information.
runtimeservices_dynamic
This example shows how to use srTestSuiteAddSuite, srTestSuiteAddCase, srTestSuiteAddAnnotation, and srTestAnnotationAddComment for dynamic suite, test, and annotation creation in the context of a single test method.
runtimeservices_override
This example shows how to use srTestCaseSetStatus to override the status that would otherwise be inferred from the return value.
runtimeservices_varcomment
This example demonstrates the use of printf style format strings with srTestCaseAddComment.