Test Unit - Revision history

Ryanh at 19:58, 7 July 2015

2015-07-07T19:58:54Z

← Older revision		Revision as of 19:58, 7 July 2015
Line 190:		Line 190:

	#ifdef _SCL		#ifdef _SCL
	// this pragma identifies MyTest as a test class to the ~~STRIDE~~ compiler		// this pragma identifies MyTest as a test class to the Stride compiler
	#pragma scl_test_class(MyTest)		#pragma scl_test_class(MyTest)
	#endif		#endif
Line 212:		Line 212:

	#ifdef _SCL		#ifdef _SCL
	// This pragma identifies MyTest as a test c class to the ~~STRIDE~~ compiler.		// This pragma identifies MyTest as a test c class to the Stride compiler.
	// Extra instrumentation code will be generated to call MyTest_Init() before		// Extra instrumentation code will be generated to call MyTest_Init() before
	// tests are run.		// tests are run.
Line 251:		Line 251:

	#ifdef _SCL		#ifdef _SCL
	// this pragma identifies MyTest as a test unit to the ~~STRIDE~~ compiler, specifying		// this pragma identifies MyTest as a test unit to the Stride compiler, specifying
	// the four functions as members of the test unit		// the four functions as members of the test unit
	#pragma scl_test_flist("MyTest", ExpectPass, ExpectFail, ChangeMyName, ChangeMyDescription)		#pragma scl_test_flist("MyTest", ExpectPass, ExpectFail, ChangeMyName, ChangeMyDescription)

Ryanh at 16:00, 7 July 2015

2015-07-07T16:00:46Z

← Older revision		Revision as of 16:00, 7 July 2015
Line 67:		Line 67:
	'''C++ class'''		'''C++ class'''

	[[Test_Unit#~~Test_Unit_as_C.2B.2B_Class~~\|Example code]]		[[Test_Unit#C++ Class\|Example code]]


Line 83:		Line 83:
	'''C class'''		'''C class'''

	[[Test_Unit#~~Test_Unit_as_C_Class~~\|Example code]]		[[Test_Unit#C Class\|Example code]]

	\|		\|
Line 97:		Line 97:
	'''C functions'''		'''C functions'''

	[[Test_Unit#~~Test_Unit_as_Group_of_Free_Functions~~\|Example code]]		[[Test_Unit#Free Functions\|Example code]]

	\|		\|

Ryanh at 15:38, 7 July 2015

2015-07-07T15:38:26Z

← Older revision		Revision as of 15:38, 7 July 2015
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	'''Stride''' groups similar test cases into a single ''runnable'' package called a '''Test Unit''' (also known as a '''Test Suite'''). These tests are written in C and C++ ~~and~~ are compiled and linked with your software and run, when called, on your target platform. They are suitable for both developer unit testing as well as end-to-end integration testing. An external [[Stride Runner]] is provided which controls the execution of '''Test Units''' and publishes test results to the local file system and optionally to [http://www.testspace.com Testspace]. The following is an example of the structure of a '''Test Unit''':		'''Stride''' groups similar test cases into a single ''runnable'' package called a '''Test Unit''' (also known as a '''Test Suite'''). These tests are written in C and C++ which are compiled and linked with your software and run, when called, on your target platform. They are suitable for both developer unit testing as well as end-to-end integration testing. An external [[Stride Runner]] is provided which controls the execution of '''Test Units''' and publishes test results to the local file system and optionally to [http://www.testspace.com Testspace]. The following is an example of the structure of a '''Test Unit''':

	'''Declare tests'''		'''Declare tests'''
Line 42:		Line 42:
	'''Test fixturing''' refers to the ''Setup'' and ''Teardown'' phases of the testing.		'''Test fixturing''' refers to the ''Setup'' and ''Teardown'' phases of the testing.

	In the '''Setup''' phase, we put all of the things into place that are required in order to run a ~~our~~ test and expect a particular outcome. This includes things like:		In the '''Setup''' phase, we put all of the things into place that are required in order to run a test and expect a particular outcome. This includes things like:
	* Acquiring resources such as memory, hardware, etc.		* Acquiring resources such as memory, hardware, etc.
	* Setting up required states such as input files in place, memory filled with a pattern, dependencies initialized, etc.		* Setting up required states such as input files in place, memory filled with a pattern, dependencies initialized, etc.
Line 54:		Line 54:
	Grouping of individual tests into a Test Unit can be accomplished in any of three ways:		Grouping of individual tests into a Test Unit can be accomplished in any of three ways:

	* A Test Unit can be comprised of the member functions of a '''C++ class''',		* A Test Unit can be comprised of the public member functions of a '''C++ class''',
	* A Test Unit can be comprised of a set of '''C functions''',		* A Test Unit can be comprised of a set of '''C functions''',
	* A Test Unit can be comprised of C functions pointed to by members of a '''C struct'''		* A Test Unit can be comprised of C functions pointed to by members of a '''C struct'''
Line 115:		Line 115:
	== Test Method Return Values ==		== Test Method Return Values ==

	Test Method return values must conform to certain return types as ~~summarizing~~ in the following table.		Test Method return values must conform to certain return types as summarized in the following table.


Line 166:		Line 166:
	== Examples ==		== Examples ==

	Following are a few short examples. In each example, a single test unit with the name "MyTest" is identified to the Stride compiler via a [[Test Pragmas]].		Following are a few short examples. In each example, a single test unit with the name "MyTest" is identified to the Stride compiler via [[Test Pragmas]].

	=== C++ Class ===		=== C++ Class ===

Ryanh at 15:17, 7 July 2015

2015-07-07T15:17:52Z

← Older revision		Revision as of 15:17, 7 July 2015
Line 6:		Line 6:
	#include <srtest.h>		#include <srtest.h>

	class MyTest {		class MyTest : public stride::srTest {
	public:		public:
	void CheckFoo();		void CheckFoo();

Marku: /* Test Method Return Values */

2015-07-07T02:45:23Z

Test Method Return Values

← Older revision		Revision as of 02:45, 7 July 2015
Line 127:		Line 127:
	\| Most common return type		\| Most common return type
	\| Since there is no return, PASS/FAIL status is set in the body of the method using a		\| Since there is no return, PASS/FAIL status is set in the body of the method using a
	* [[Test_Macros\|~~test macro~~]]		* [[Test_Macros\|Test Macro]]
	or a runtime call		or a runtime call
	* [[Runtime_Test_Services#srTestCaseSetStatus\|srTestCaseSetStatus()]]		* [[Runtime_Test_Services#srTestCaseSetStatus\|srTestCaseSetStatus()]]

Marku at 16:39, 6 July 2015

2015-07-06T16:39:00Z

← Older revision		Revision as of 16:39, 6 July 2015
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	'''Stride''' groups similar test cases into a single ''runnable'' package called a '''Test Unit''' (also known as a '''Test Suite'''). These tests are written in C and C++ and are compiled and linked with your software and run, when called, on your target platform. They are suitable for both developer unit testing as well as end-to-end integration testing. An external ~~Stride~~ [[Stride ~~Runner\|~~ Runner]] is provided which controls the execution of '''Test Units''' and publishes test results to the local file system and optionally to [http://www.testspace.com Testspace]. The following is an example of the structure of a '''Test Unit''':		'''Stride''' groups similar test cases into a single ''runnable'' package called a '''Test Unit''' (also known as a '''Test Suite'''). These tests are written in C and C++ and are compiled and linked with your software and run, when called, on your target platform. They are suitable for both developer unit testing as well as end-to-end integration testing. An external [[Stride Runner]] is provided which controls the execution of '''Test Units''' and publishes test results to the local file system and optionally to [http://www.testspace.com Testspace]. The following is an example of the structure of a '''Test Unit''':

	'''Declare tests'''		'''Declare tests'''

Marku at 16:27, 6 July 2015

2015-07-06T16:27:15Z

← Older revision		Revision as of 16:27, 6 July 2015
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	'''Stride''' groups similar test cases into a single ''runnable'' package called a '''Test Unit''' (also known as a '''Test Suite'''). These tests are written in C and C++ and are compiled and linked with your software and run, when called, on your target platform. They are suitable for both developer unit testing as well as end-to-end integration testing. An external [[Stride Runner\|~~Test~~ Runner]] is provided which controls the execution of '''Test Units''' and publishes test results to the local file system and optionally to [http://www.testspace.com Testspace]. The following is an example of the structure of a '''Test Unit''':		'''Stride''' groups similar test cases into a single ''runnable'' package called a '''Test Unit''' (also known as a '''Test Suite'''). These tests are written in C and C++ and are compiled and linked with your software and run, when called, on your target platform. They are suitable for both developer unit testing as well as end-to-end integration testing. An external Stride [[Stride Runner\| Runner]] is provided which controls the execution of '''Test Units''' and publishes test results to the local file system and optionally to [http://www.testspace.com Testspace]. The following is an example of the structure of a '''Test Unit''':

	'''Declare tests'''		'''Declare tests'''
Line 166:		Line 166:
	== Examples ==		== Examples ==

	Following are a few short examples. In each example, a single test unit with the name "MyTest" is identified to the Stride compiler via a ~~custom~~ [[Test ~~Unit Pragmas2\| Stride pragma~~]].		Following are a few short examples. In each example, a single test unit with the name "MyTest" is identified to the Stride compiler via a [[Test Pragmas]].

	=== C++ Class ===		=== C++ Class ===
Line 278:		Line 278:
	=== Use Operator << to Augment Test Macros ===		=== Use Operator << to Augment Test Macros ===

	In C++ test code [[~~Test Point2 \|~~ Test Point]], [[Test Log]] and [[Test Macros]] macros support adding to the annotation using the << operator. For example:		In C++ test code [[Test Point]], [[Test Log]] and [[Test Macros]] macros support adding to the annotation using the << operator. For example:

	<source lang="cpp">		<source lang="cpp">

Marku: /* Packaging */

2015-07-06T15:30:46Z

Packaging

← Older revision		Revision as of 15:30, 6 July 2015
Line 91:		Line 91:
	\|		\|
	* Requires initialization code for structure function pointer setup		* Requires initialization code for structure function pointer setup
	* [[Test_Documentation_in_C/C%2B%2B\|Test ~~unit~~ documentation]] must be associated with the structure function pointer members instead of the actual test method implementations.		* [[Test_Documentation_in_C/C%2B%2B\|Test Unit documentation]] must be associated with the structure function pointer members instead of the actual test method implementations.
	\| <tt>scl_test_cclass</tt>		\| <tt>scl_test_cclass</tt>
	\|-		\|-
Line 105:		Line 105:
	* No test unit support for constructor/initializer or destructor/de-initializer		* No test unit support for constructor/initializer or destructor/de-initializer
	* Changing test unit membership requires editing of the pragma statement		* Changing test unit membership requires editing of the pragma statement
	* [[Test_Documentation_in_C/C%2B%2B\|Test ~~unit~~ documentation]] for the FList must be associated with the header file - as such, you can only have one FList per header file if you want to document your test units.		* [[Test_Documentation_in_C/C%2B%2B\|Test Unit documentation]] for the FList must be associated with the header file - as such, you can only have one FList per header file if you want to document your test units.
	\| <tt>scl_test_flist</tt>		\| <tt>scl_test_flist</tt>
	\|}		\|}

Marku: /* Use Operator << to Augment Test Macros */

2015-07-06T15:06:11Z

Use Operator << to Augment Test Macros

← Older revision		Revision as of 15:06, 6 July 2015
Line 278:		Line 278:
	=== Use Operator << to Augment Test Macros ===		=== Use Operator << to Augment Test Macros ===

	In C++ test code [[Test Point]], [[Test Log]] and [[Test ~~Code~~ Macros~~\|Test Code~~]] macros support adding to the annotation using the << operator. For example:		In C++ test code [[Test Point2 \| Test Point]], [[Test Log]] and [[Test Macros]] macros support adding to the annotation using the << operator. For example:

	<source lang="cpp">		<source lang="cpp">
Line 287:		Line 287:
	* all numeric types,		* all numeric types,
	* C string (char* or wchar_t*), and		* C string (char* or wchar_t*), and
	* types allowing implicit cast to numeric type or "C" string.		* types allowing implicit cast to numeric type or "C" string.

	=== Overloading the << operator ===		=== Overloading the << operator ===

Marku: /* Examples */

2015-07-06T14:52:30Z

Examples

← Older revision		Revision as of 14:52, 6 July 2015
Line 166:		Line 166:
	== Examples ==		== Examples ==

	Following are a few short examples. In each example, a single test unit with the name "MyTest" is identified to the ~~[[s2scompile\|STRIDE~~ compiler]] via a custom [[Test Unit ~~Pragmas~~\|~~special test~~ pragma]].		Following are a few short examples. In each example, a single test unit with the name "MyTest" is identified to the Stride compiler via a custom [[Test Unit Pragmas2\| Stride pragma]].

	=== C++ Class ===		=== C++ Class ===