Test Class Sample: Difference between revisions
(→srTest) |
|||
Line 45: | Line 45: | ||
===srTest=== | ===srTest=== | ||
These examples show to how to use the [[ | These examples show to how to use the [[Runtime_Test_Services#C.2B.2B_Test_Classes|stride::srTest]] base class for your test classes. When you publicly inherit from srTest, you get access to default testCase and testSuite members and their associated methods. | ||
====srTest::Simple==== | ====srTest::Simple==== | ||
This example demonstrates the use of [[ | This example demonstrates the use of [[Runtime_Test_Services#SetStatus|testCase.setStatus]] to set the status for test cases. | ||
====srTest::Dynamic==== | ====srTest::Dynamic==== | ||
This example demonstrates how to use [[ | This example demonstrates how to use [[Runtime_Test_Services#AddSuite|testSuite.AddSuite]], [[Runtime_Test_Services#AddTest|testSuite.AddTest]], [[Runtime_Test_Services#AddAnnotation|testSuite.AddAnnotation]], and [[Runtime_Test_Services#AddAnnotation.AddComment|testSuite.AddAnnotation.AddComment]] for dynamic suite, test case, and annotation creation within the context of one test method. | ||
[[Category: Samples]] | [[Category: Samples]] |
Revision as of 23:32, 21 August 2009
Introduction
These examples cover the use of Test Classes to create logical groupings of test cases. For unit testing, one test class is typically created for each class under test, although more complicated scenarios often justify other arrangements. Test Classes require a c++ compiler.
NOTE: each of the example test classes is grouped in namespace corresponding to its category (e.g. Basic or Runtime Services). This is something shown for organizational purposes only -- it is not a general requirement that test classes be placed into namespaces.
Tests Description
Basic
These examples cover the simplest, easiest way to code a STRIDE test class. These examples use simple POD return types to indicate status.
Basic::Simple
This example demonstrates passing and failing tests using the four primary POD types that infer status from (int, bool, short, and char).
Basic::Fixtures
This example demonstrates 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.
Basic::Exceptions
This example demonstrates how exceptions thrown from a test method are caught by the intercept module and noted in the results. Any exception that is caught by the harness is assumed to indicate failure. If you want to write tests for expected exceptions, consider using our exception macros
Runtime Services
These examples cover basic usage of the Runtime Test Services API (as declared in srtest.h).
RuntimeServices::Simple
This example demonstrates 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 demonstrates 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 demonstrates 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.
srTest
These examples show to how to use the stride::srTest base class for your test classes. When you publicly inherit from srTest, you get access to default testCase and testSuite members and their associated methods.
srTest::Simple
This example demonstrates the use of testCase.setStatus to set the status for test cases.
srTest::Dynamic
This example demonstrates how to use testSuite.AddSuite, testSuite.AddTest, testSuite.AddAnnotation, and testSuite.AddAnnotation.AddComment for dynamic suite, test case, and annotation creation within the context of one test method.