Test Class Sample - Revision history

Ivailop: /* Observations */

2018-12-28T19:00:28Z

Observations

← Older revision		Revision as of 19:00, 28 December 2018
Line 75:		Line 75:
	The following are some test observations:		The following are some test observations:
	* all of these example classes have been put into one or more namespaces. This is just for organization purposes, mainly to avoid name collisions when built along with lots of other test classes. Your test classes are '''not''' required to be in namespaces, but it can be helpful in avoiding collisions as the number of tests in your system grows.		* all of these example classes have been put into one or more namespaces. This is just for organization purposes, mainly to avoid name collisions when built along with lots of other test classes. Your test classes are '''not''' required to be in namespaces, but it can be helpful in avoiding collisions as the number of tests in your system grows.
	* we've documented our test classes and methods using [~~http~~://~~www~~.~~stack~~.nl/~~~dimitri/doxygen~~/ doxygen] style comments. This documentation is automatically extracted by our tools and added to the results report - more information about this feature is [[Test_Documentation_in_C/C%2B%2B\|here]]		* we've documented our test classes and methods using [https://en.wikipedia.org/wiki/Doxygen doxygen] style comments. This documentation is automatically extracted by our tools and added to the results report - more information about this feature is [[Test_Documentation_in_C/C%2B%2B\|here]]
	* you can optionally write test classes that inherit from a base class that we've defined ([[Runtime_Test_Services#class_srTest\|stride::srTest]]). We recommend you start by writing your classes this way so that your classes will inherit some methods and members that make some custom reporting tasks simpler.		* you can optionally write test classes that inherit from a base class that we've defined ([[Runtime_Test_Services#class_srTest\|stride::srTest]]). We recommend you start by writing your classes this way so that your classes will inherit some methods and members that make some custom reporting tasks simpler.
	* exceptions are generally handled by the STRIDE unit test harness, but can be disabled if your compiler does not support them (see ''s2_testclass_basic_exceptions_tests.h/cpp'').		* exceptions are generally handled by the STRIDE unit test harness, but can be disabled if your compiler does not support them (see ''s2_testclass_basic_exceptions_tests.h/cpp'').

Ivailop: /* RuntimeServices::Dynamic */

2014-08-05T19:32:00Z

RuntimeServices::Dynamic

← Older revision		Revision as of 19:32, 5 August 2014
Line 37:		Line 37:
	====RuntimeServices::Dynamic====		====RuntimeServices::Dynamic====

	This example demonstrates how to use [[Runtime_Test_Services#srTestSuiteAddCase\|srTestSuiteAddCase]], [[Runtime_Test_Services#srTestSuiteAddAnnotation\|srTestSuiteAddAnnotation]], and [[Runtime_Test_Services#srTestAnnotationAddComment\|srTestAnnotationAddComment]] for dynamic ~~suite, test~~, and annotation creation in the context of a single test method.		This example demonstrates how to use [[Runtime_Test_Services#srTestSuiteAddCase\|srTestSuiteAddCase]], [[Runtime_Test_Services#srTestSuiteAddAnnotation\|srTestSuiteAddAnnotation]], and [[Runtime_Test_Services#srTestAnnotationAddComment\|srTestAnnotationAddComment]] for dynamic case, and annotation creation in the context of a single test method.

	====RuntimeServices::Override====		====RuntimeServices::Override====

Ivailop: /* srTest::Dynamic */

2014-08-05T19:31:09Z

srTest::Dynamic

← Older revision		Revision as of 19:31, 5 August 2014
Line 57:		Line 57:
	====srTest::Dynamic====		====srTest::Dynamic====

	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.		This example demonstrates how to use [[Runtime_Test_Services#method_AddCase\|AddCase]], [[Runtime_Test_Services#method_AddAnnotation_2\|testCase.AddAnnotation]], and [[Runtime_Test_Services#method_AddComment\|testAnnotation.AddComment]] for dynamic test case, and annotation creation within the context of one test method.

	== Run Tests ==		== Run Tests ==

Ivailop: /* Tests Description */

2014-08-05T19:27:22Z

Tests Description

← Older revision		Revision as of 19:27, 5 August 2014
Line 33:		Line 33:
	====RuntimeServices::Simple====		====RuntimeServices::Simple====

	This example demonstrates how to use [[Runtime_Test_Services#srTestCaseSetStatus\|srTestCaseSetStatus]] to set status and [[Runtime_Test_Services#~~srTestCaseAddComment~~\|~~srTestCaseAddComment~~]] to add a comment.		This example demonstrates how to use [[Runtime_Test_Services#srTestCaseSetStatus\|srTestCaseSetStatus]] to set status and [[Runtime_Test_Services#srTestCaseAddAnnotation\|srTestCaseAddAnnotation]] to add a comment.

	====RuntimeServices::Dynamic====		====RuntimeServices::Dynamic====
Line 45:		Line 45:
	====RuntimeServices::VarComment====		====RuntimeServices::VarComment====

	This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Runtime_Test_Services#~~srTestCaseAddComment~~\|~~srTestCaseAddComment~~]].		This example demonstrates the use of [http://en.wikipedia.org/wiki/Printf printf] style format strings with [[Runtime_Test_Services#srTestCaseAddAnnotation\|srTestCaseAddAnnotation]].

	===srTest===		===srTest===

Ivailop: /* RuntimeServices::Dynamic */

2014-08-05T19:22:06Z

RuntimeServices::Dynamic

← Older revision		Revision as of 19:22, 5 August 2014
Line 37:		Line 37:
	====RuntimeServices::Dynamic====		====RuntimeServices::Dynamic====

	This example demonstrates how to use ~~[[Runtime_Test_Services#srTestSuiteAddSuite\|srTestSuiteAddSuite]],~~ [[Runtime_Test_Services#srTestSuiteAddCase\|srTestSuiteAddCase]], [[Runtime_Test_Services#srTestSuiteAddAnnotation\|srTestSuiteAddAnnotation]], and [[Runtime_Test_Services#srTestAnnotationAddComment\|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method.		This example demonstrates how to use [[Runtime_Test_Services#srTestSuiteAddCase\|srTestSuiteAddCase]], [[Runtime_Test_Services#srTestSuiteAddAnnotation\|srTestSuiteAddAnnotation]], and [[Runtime_Test_Services#srTestAnnotationAddComment\|srTestAnnotationAddComment]] for dynamic suite, test, and annotation creation in the context of a single test method.

	====RuntimeServices::Override====		====RuntimeServices::Override====

Ivailop: /* Observations */

2012-02-27T23:49:18Z

Observations

← Older revision		Revision as of 23:49, 27 February 2012
Line 75:		Line 75:
	The following are some test observations:		The following are some test observations:
	* all of these example classes have been put into one or more namespaces. This is just for organization purposes, mainly to avoid name collisions when built along with lots of other test classes. Your test classes are '''not''' required to be in namespaces, but it can be helpful in avoiding collisions as the number of tests in your system grows.		* all of these example classes have been put into one or more namespaces. This is just for organization purposes, mainly to avoid name collisions when built along with lots of other test classes. Your test classes are '''not''' required to be in namespaces, but it can be helpful in avoiding collisions as the number of tests in your system grows.
	* we've documented our test classes and methods using [http://www.stack.nl/~dimitri/doxygen/ doxygen] style comments. This documentation is automatically extracted by our tools and added to the results report - more information about this feature is [[~~Test_API#Test_Documentation~~\|here]]		* we've documented our test classes and methods using [http://www.stack.nl/~dimitri/doxygen/ doxygen] style comments. This documentation is automatically extracted by our tools and added to the results report - more information about this feature is [[Test_Documentation_in_C/C%2B%2B\|here]]
	* you can optionally write test classes that inherit from a base class that we've defined ([[Runtime_Test_Services#class_srTest\|stride::srTest]]). We recommend you start by writing your classes this way so that your classes will inherit some methods and members that make some custom reporting tasks simpler.		* you can optionally write test classes that inherit from a base class that we've defined ([[Runtime_Test_Services#class_srTest\|stride::srTest]]). We recommend you start by writing your classes this way so that your classes will inherit some methods and members that make some custom reporting tasks simpler.
	* exceptions are generally handled by the STRIDE unit test harness, but can be disabled if your compiler does not support them (see ''s2_testclass_basic_exceptions_tests.h/cpp'').		* exceptions are generally handled by the STRIDE unit test harness, but can be disabled if your compiler does not support them (see ''s2_testclass_basic_exceptions_tests.h/cpp'').

Ivailop: /* RuntimeServices::Simple */

2011-07-05T23:30:09Z

RuntimeServices::Simple

← Older revision		Revision as of 23:30, 5 July 2011
Line 33:		Line 33:
	====RuntimeServices::Simple====		====RuntimeServices::Simple====

	This example demonstrates how to use [[Runtime_Test_Services#srTestCaseSetStatus\|srTestCaseSetStatus]] to set status, [[Runtime_Test_Services#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 demonstrates how to use [[Runtime_Test_Services#srTestCaseSetStatus\|srTestCaseSetStatus]] to set status and [[Runtime_Test_Services#srTestCaseAddComment\|srTestCaseAddComment]] to add a comment.

	====RuntimeServices::Dynamic====		====RuntimeServices::Dynamic====

Marku at 16:32, 9 June 2011

2011-06-09T16:32:35Z

← Older revision		Revision as of 16:32, 9 June 2011
Line 58:		Line 58:

	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.		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.

			== Run Tests ==

			Now launch the test app (if you have not already) and execute the runner with the following commands:

			''Test Class tests'':
			<pre>
			stride --device="TCP:localhost:8000" --database="../out/TestApp.sidb" --run="s2_testclass::Basic::Exceptions; s2_testclass::Basic::Fixtures; s2_testclass::Basic::Parameterized; s2_testclass::Basic::Simple" --output=TestClass.xml
			</pre>

			Note the command will produce distinct result files for the run (per the ''--output'' command above). Please use the result file to peruse the results by opening each in your browser.

			== Observations ==
			This sample shows the techniques available for packaging and writing test units using classes. If you have a C++ capable compiler, we recommend that you use test classes to package your unit tests, even if your APIs under test are C only. Review the source code in the directory and follow the sample description.

			The following are some test observations:
			* all of these example classes have been put into one or more namespaces. This is just for organization purposes, mainly to avoid name collisions when built along with lots of other test classes. Your test classes are '''not''' required to be in namespaces, but it can be helpful in avoiding collisions as the number of tests in your system grows.
			* we've documented our test classes and methods using [http://www.stack.nl/~dimitri/doxygen/ doxygen] style comments. This documentation is automatically extracted by our tools and added to the results report - more information about this feature is [[Test_API#Test_Documentation\|here]]
			* you can optionally write test classes that inherit from a base class that we've defined ([[Runtime_Test_Services#class_srTest\|stride::srTest]]). We recommend you start by writing your classes this way so that your classes will inherit some methods and members that make some custom reporting tasks simpler.
			* exceptions are generally handled by the STRIDE unit test harness, but can be disabled if your compiler does not support them (see ''s2_testclass_basic_exceptions_tests.h/cpp'').
			* parameterized tests are supported by test classes as well. In these tests, simple constructor arguments can be passed during execution and are available at runtime to the test unit. The STRIDE infrastructure handles the passing of the arguments to the device and the construction of the test class with these arguments. Parameterization of test classes can be a powerful way to expand your test coverage with data driven test scenarios (varying the input to a single test class).


	[[Category: Samples]]		[[Category: Samples]]

Marku: moved Test Class Samples to Test Class Sample over redirect

2011-06-06T23:15:17Z

moved Test Class Samples to Test Class Sample over redirect

← Older revision	Revision as of 23:15, 6 June 2011
(No difference)

Marku: /* Basic::Exceptions */

2010-06-02T23:07:38Z

Basic::Exceptions

← Older revision		Revision as of 23:07, 2 June 2010
Line 21:		Line 21:
	====Basic::Exceptions====		====Basic::Exceptions====

	This example demonstrates 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 [[~~Pass/Fail_Macros~~#Exception_Macros\|exception macros]]		This example demonstrates 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 [[Test Macros#Exception_Macros\|exception macros]]

	====Basic::Parameterized====		====Basic::Parameterized====