Stride Overview - Revision history

Ivailop at 23:40, 21 May 2021

2021-05-21T23:40:03Z

← Older revision		Revision as of 23:40, 21 May 2021
Line 39:		Line 39:
	Test cases are typically constructed leveraging a large set of available assertion macros. When failures occur, these macros automatically set test status and provide details to the test report such as file name, line number, and condition causing the failure. Stride provides a large set of these macros to validate a wide variety of scenarios.		Test cases are typically constructed leveraging a large set of available assertion macros. When failures occur, these macros automatically set test status and provide details to the test report such as file name, line number, and condition causing the failure. Stride provides a large set of these macros to validate a wide variety of scenarios.

	<source lang=cpp>		<source lang="cpp">
	#include <mytest.h>		#include <mytest.h>

Line 58:		Line 58:
	Create an INI-type of file (i.e. ''myinput.ini'')		Create an INI-type of file (i.e. ''myinput.ini'')

	<source lang=ini>		<source lang="ini">
	Loopsize = 10		Loopsize = 10
	InputFile = ${MYPATH}/datacontent.bin		InputFile = ${MYPATH}/datacontent.bin
Line 66:		Line 66:
	Pass the name-value collection using the Stride Runner		Pass the name-value collection using the Stride Runner

	<source lang=bash>		<source lang="bash">
	$ stride .. --run="MyTest(/path/to/myinput.ini)"		$ stride .. --run="MyTest(/path/to/myinput.ini)"
	</source>		</source>
Line 72:		Line 72:
	Now simply access your input within test logic using built-in services		Now simply access your input within test logic using built-in services

	<source lang=cpp>		<source lang="cpp">
	{		{
	// .. doing stuff ..		// .. doing stuff ..
Line 88:		Line 88:
	For example something like the following could be useful:		For example something like the following could be useful:

	<source lang=cpp>		<source lang="cpp">
	void MySuite::test1()		void MySuite::test1()
	{		{
Line 106:		Line 106:
	Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions/methods but rather verifies ''code execution sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.		Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions/methods but rather verifies ''code execution sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.

	<source lang='c'>		<source lang="c">

	/* a test point with formatted string payload */		/* a test point with formatted string payload */
Line 121:		Line 121:

	The following is a snippet of what the test code might look like		The following is a snippet of what the test code might look like
	<source lang='c'>		<source lang="c">

	srTestPointExpect_t expected[]={		srTestPointExpect_t expected[]={
Line 143:		Line 143:

	'''C/C++ Test Example'''		'''C/C++ Test Example'''
	<source lang=cpp>		<source lang="cpp">
	#include <srtest.h>		#include <srtest.h>

Line 155:		Line 155:


	<source lang=cpp>		<source lang="cpp">
	#include <mytest.h>		#include <mytest.h>

Ivailop at 23:35, 21 May 2021

2021-05-21T23:35:15Z

← Older revision		Revision as of 23:35, 21 May 2021
Line 121:		Line 121:

	The following is a snippet of what the test code might look like		The following is a snippet of what the test code might look like
	<source = lang='c'>		<source lang='c'>

	srTestPointExpect_t expected[]={		srTestPointExpect_t expected[]={

Ivailop: /* Test Implementation */

2015-07-09T20:01:14Z

Test Implementation

← Older revision		Revision as of 20:01, 9 July 2015
Line 164:		Line 164:
	void MyTest::CheckBoo() {		void MyTest::CheckBoo() {
	..		..
	~~srEXPECT_GT~~(boo(3 * 3), 7);		srASSERT_GT(boo(3 * 3), 7);
	}		}
	</source>		</source>
Line 185:		Line 185:
	sub CheckBoo : Test		sub CheckBoo : Test
	{		{
	~~EXPECT_GT~~(Remote->boo(3 * 3), 7);		ASSERT_GT(Remote->boo(3 * 3), 7);
	}		}

Ivailop at 19:57, 9 July 2015

2015-07-09T19:57:02Z

← Older revision		Revision as of 19:57, 9 July 2015
Line 66:		Line 66:
	Pass the name-value collection using the Stride Runner		Pass the name-value collection using the Stride Runner

	$ stride .. --run="MyTest(/path/to/myinput.ini)"		<source lang=bash>
			$ stride .. --run="MyTest(/path/to/myinput.ini)"
			</source>

	Now simply access your input within test logic using built-in services		Now simply access your input within test logic using built-in services
Line 102:		Line 104:

	==== Test Points ====		==== Test Points ====
	Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions / methods but rather verifies ''code execution sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.		Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions/methods but rather verifies ''code execution sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.

	<source lang='c'>		<source lang='c'>
Line 121:		Line 123:
	<source = lang='c'>		<source = lang='c'>

	srTestPointExpect_t expected[]={		srTestPointExpect_t expected[]={
	{"IMPORTANT"}, myCheckData,		{"IMPORTANT"}, myCheckData,
	{"ANOTHER_TP"},		{"ANOTHER_TP"},
	{0}};		{0}};

	// setup the expections		// setup the expections
	srTestPointSetup(..);		srTestPointSetup(expected, ..);

	// start the operations		// start the operations

	srTestPointWait(handle, 1000);		srTestPointWait(handle, 1000);

	</source>		</source>

Ivailop at 19:47, 9 July 2015

2015-07-09T19:47:15Z

← Older revision		Revision as of 19:47, 9 July 2015
Line 37:		Line 37:

	== Rich set of Assertions ==		== Rich set of Assertions ==
	Test cases are typically constructed leveraging a large set of available assertion macros. When failures occur, these macros automatically set test status and provide details to the test report such as file name, line number, and condition causing the failure. Stride provides a large set of these macros to validate a wide variety of ~~validation~~ scenarios.		Test cases are typically constructed leveraging a large set of available assertion macros. When failures occur, these macros automatically set test status and provide details to the test report such as file name, line number, and condition causing the failure. Stride provides a large set of these macros to validate a wide variety of scenarios.

	<source lang=cpp>		<source lang=cpp>
Line 48:		Line 48:
	void MyTest::CheckBoo() {		void MyTest::CheckBoo() {
	..		..
	~~srEXPECT_GT~~(boo(3 * 3), 7);		srASSERT_GT(boo(3 * 3), 7);
	}		}
	</source>		</source>
Line 54:		Line 54:
	== Extensive Parameter Support ==		== Extensive Parameter Support ==

	Parameterized testing is key to reducing test code duplication. Constructor arguments, name-value ~~collections~~, and host file remoting are all supported. Stride provides an easy way for passing and accessing these types of parameters, allowing customization of test behavior at runtime.		Parameterized testing is key to reducing test code duplication. Constructor arguments, name-value collection, and host file remoting are all supported. Stride provides an easy way for passing and accessing these types of parameters, allowing customization of test behavior at runtime.

	Create an INI-type of file (i.e. myinput.ini)		Create an INI-type of file (i.e. ''myinput.ini'')

	Loopsize = 10		<source lang=ini>
	InputFile = ${MYPATH}/datacontent.bin		Loopsize = 10
	Toogle = On		InputFile = ${MYPATH}/datacontent.bin
			Toogle = On
			</source>

	Pass the name-value collection using the Stride Runner		Pass the name-value collection using the Stride Runner
Line 71:		Line 73:
	{		{
	// .. doing stuff ..		// .. doing stuff ..
	GetParam("~~Loopsize~~", buffer, size);		GetParam("InputFile", buffer, size);
	//.. using parameters for test logic		//.. using parameters for test logic
	}		}

Ivailop at 19:34, 9 July 2015

2015-07-09T19:34:15Z

← Older revision		Revision as of 19:34, 9 July 2015
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	'''Stride™''' is an [http://en.wikipedia.org/wiki/XUnit xUnit-style] test framework for C/C++ software comprised of an external test ''Runner'' , ''Runtime'' source code library, and a set of ''Build Tools''. It was designed with a specific focus on enabling tests to be executed on a device using a fully functional build. ~~This~~ means that the software works the same as before instrumentation, but now has built-in tests that can be invoked on-demand by the test ''Runner''.		'''Stride™''' is an [http://en.wikipedia.org/wiki/XUnit xUnit-style] test framework for C/C++ software comprised of an external test ''Runner'', ''Runtime'' source code library, and a set of ''Build Tools''. It was designed with a specific focus on enabling tests to be executed on a device using a fully functional build.<ref>Fully functional build means that the software works the same as before instrumentation, but now has built-in tests that can be invoked on-demand by the test ''Runner''.</ref>

	Stride's unique host-target architecture allows easier and better On-Target/Device White-box testing. Software builds automatically become more testable; facilitating deeper code coverage opportunities.		Stride's unique host-target architecture allows easier and better On-Target/Device White-box testing. Software builds automatically become more testable; facilitating deeper code coverage opportunities.<ref>For more details refer to our [[Frequently Asked Questions About STRIDE \| FAQ]].</ref>

	Stride is also fully integrated with [http://www.testspace.com Testspace] for test content management.		Stride is also fully integrated with [http://www.testspace.com Testspace] for test content management.
Line 15:		Line 15:

	====Runtime====		====Runtime====
	Stride also contains a [[STRIDE Runtime \| '''Runtime''']] software source package ~~that supports connectivity with the host system~~. The Runtime enables ''testability'' by integrating with the software under test, all with minimal impact on performance or code size. The software is agnostic to the RTOS, CPU, and host/device I/O transport. It supports simple single-process devices as well as multi-process and multi-threaded environments. It can be used with software running in either user or kernel mode, including drivers. Typically the ~~runtime~~ is configured as a background thread and only executes when running tests.		Stride also contains a [[STRIDE Runtime \| '''Runtime''']] software source package. The Runtime enables ''testability'' by integrating with the software under test along with supporting connectivity with the host system, all with minimal impact on performance or code size. The software is agnostic to the RTOS, CPU, and host/device I/O transport. It supports simple ''single-process'' devices as well as ''multi-process'' and ''multi-threaded'' environments. It can be used with software running in either user or kernel mode, including drivers. Typically the Runtime is configured as a background thread and only executes when running tests.

	==== Build Tools ====		==== Build Tools ====
	[[image:STRIDE 4.2 Framework-b.jpg \|right\|~~300px~~ \| border]]		[[image:STRIDE 4.2 Framework-b.jpg \|right\|250px \| border]]

	The Stride [[STRIDE_Build_Tools \| '''Build Tools''']] are a set of command-line utilities that integrate with your target software build process. They preprocess standard C/C++ header files that contain Stride test declarations to auto-generate C or C++ source code comprising a custom [[Intercept_Module \| '''Intercept Module''']]. The intercept module code is then included in your target software build along with the Stride Runtime to provide ''fixturing'' and ''harnessing'' test logic as part of your build image.		The Stride [[STRIDE_Build_Tools \| '''Build Tools''']] are a set of command-line utilities that integrate with your target software build process. They preprocess standard C/C++ header files that contain Stride test declarations to auto-generate C/C++ source code comprising a custom [[Intercept_Module \| '''Intercept Module''']]. The intercept module code is then included in your target software build along with the Stride Runtime to provide ''fixturing'' and ''harnessing'' test logic as part of your build image.

	== Cross Platform ==		== Cross Platform ==
	Stride works on virtually any target platform. Stride's cross-platform framework facilitates a ''unified testing approach'' for all team members, enabling organizations to standardize on a test workflow that is independent of the target platform being used or what branch of software is being changed.		Stride works on virtually any target platform. Stride's cross-platform framework facilitates a ''unified testing approach'' for all team members, enabling organizations to standardize on a test workflow that is independent of the target platform being used or what branch of software is being changed.

	=== Runtime Written in Standard C ===		==== Runtime Written in Standard C ====
	The Stride Runtime is written in standard ANSI C on top of a simple customizable [[Platform_Abstraction_Layer \| '''platform abstraction layer''']] that enables it to work across platforms. It can be configured for a single process multi-threading environment or multiple process environments (i.e. Android, Linux, Windows, Embedded RTOS, etc.). It is delivered as source code to be included in the application's build system. The transport between the host and target is configurable and supports Serial and TCP/IP by default. Custom transports are also available.		The Stride Runtime is written in standard ANSI C on top of a simple customizable [[Platform_Abstraction_Layer \| '''platform abstraction layer''']] that enables it to work across platforms. It can be configured for a single process multi-threading environment or multiple process environments (i.e. Android, Linux, Windows, Embedded RTOS, etc.). It is delivered as source code to be included in the application's build system. The transport between the host and target is configurable and supports Serial and TCP/IP by default. Custom transports are also available.

	The runtime has been tailored specifically for embedded applications; overhead is minimal. It consumes very little memory for table and control block storage. Resource usage is configurable and can be adjusted to conform to any limitations of the target platform.		The runtime has been tailored specifically for embedded applications; overhead is minimal. It consumes very little memory for table and control block storage. Resource usage is configurable and can be adjusted to conform to any limitations of the target platform.

	===Integrates With Your Existing Build System ===		==== Integrates With Your Existing Build System ====
	Stride auto-generates ''intercept module'' harnessing and remoting functionality as C or C++ source code during the make process, removing any dependencies on specific compilers and / or processors.		Stride auto-generates ''intercept module'' harnessing and remoting functionality as C or C++ source code during the make process, removing any dependencies on specific compilers and / or processors.

	===Supports Off-Target Testing ===		==== Supports Off-Target Testing ====
	~~On-target testing~~ can also be simulated using a standard desktop computer(Windows, Linux, or FreeBSD) with no changes to test code. The Stride ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.		Testing can also be simulated using a standard desktop computer (Windows, Linux, or FreeBSD) with no changes to test code. The Stride ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.

	== Rich set of Assertions ==		== Rich set of Assertions ==
Line 76:		Line 76:
	</source>		</source>

			== Test Doubles & Test Points ==
	= Test Doubles & Test Points =
	Stride offers advanced testing techniques that enable deeper and more effective testing with less effort.		Stride offers advanced testing techniques that enable deeper and more effective testing with less effort.

	===Test Doubles===		==== Test Doubles ====
	For more advanced testing scenarios, dependencies can be '''doubled'''. This feature provides a means for intercepting C/C++ global functions on the target and substituting a stub, fake, or mock. The substitution is all controllable via the runtime, allowing the software to continue executing normally when not running a test.		For more advanced testing scenarios, dependencies can be '''doubled'''. This feature provides a means for intercepting C/C++ global functions on the target and substituting a stub, fake, or mock. The substitution is all controllable via the runtime, allowing the software to continue executing normally when not running a test.

Line 100:		Line 99:
	</source>		</source>

			==== Test Points ====
	===Test Points ===
	Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions / methods but rather verifies ''code execution sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.		Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions / methods but rather verifies ''code execution sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.

Line 110:		Line 108:

	</source>		</source>


	The test validation is done without impacting the application's performance (the on-target test code is executed in a background thread and scripts are executed on the host machine). When failures do occur, context is provided with the file name and associated line number of the failed expectations. This type of validation can be applied to a wide-range of testing scenarios:		The test validation is done without impacting the application's performance (the on-target test code is executed in a background thread and scripts are executed on the host machine). When failures do occur, context is provided with the file name and associated line number of the failed expectations. This type of validation can be applied to a wide-range of testing scenarios:
Line 140:		Line 137:

	The test validation can be implemented in both ''C/C++'' on the target and ''Perl'' on the host.		The test validation can be implemented in both ''C/C++'' on the target and ''Perl'' on the host.


	'''C/C++ Test Example'''		'''C/C++ Test Example'''
Line 197:		Line 193:

	<hr/>		<hr/>
			<references/>
	<~~font size="3"~~>
	~~'''For more details refer to our [[Frequently Asked Questions About STRIDE \| FAQ]] '''~~

Ivailop at 19:05, 9 July 2015

2015-07-09T19:05:08Z

← Older revision		Revision as of 19:05, 9 July 2015
Line 22:		Line 22:
	The Stride [[STRIDE_Build_Tools \| '''Build Tools''']] are a set of command-line utilities that integrate with your target software build process. They preprocess standard C/C++ header files that contain Stride test declarations to auto-generate C or C++ source code comprising a custom [[Intercept_Module \| '''Intercept Module''']]. The intercept module code is then included in your target software build along with the Stride Runtime to provide ''fixturing'' and ''harnessing'' test logic as part of your build image.		The Stride [[STRIDE_Build_Tools \| '''Build Tools''']] are a set of command-line utilities that integrate with your target software build process. They preprocess standard C/C++ header files that contain Stride test declarations to auto-generate C or C++ source code comprising a custom [[Intercept_Module \| '''Intercept Module''']]. The intercept module code is then included in your target software build along with the Stride Runtime to provide ''fixturing'' and ''harnessing'' test logic as part of your build image.

	= Cross Platform =		== Cross Platform ==
	Stride works on virtually any target platform. Stride's cross-platform framework facilitates a ''unified testing approach'' for all team members, enabling organizations to standardize on a test workflow that is independent of the target platform being used or what branch of software is being changed.		Stride works on virtually any target platform. Stride's cross-platform framework facilitates a ''unified testing approach'' for all team members, enabling organizations to standardize on a test workflow that is independent of the target platform being used or what branch of software is being changed.

Line 36:		Line 36:
	On-target testing can also be simulated using a standard desktop computer(Windows, Linux, or FreeBSD) with no changes to test code. The Stride ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.		On-target testing can also be simulated using a standard desktop computer(Windows, Linux, or FreeBSD) with no changes to test code. The Stride ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.

	= Rich set of Assertions =		== Rich set of Assertions ==
	Test cases are typically constructed leveraging a large set of available assertion macros. When failures occur, these macros automatically set test status and provide details to the test report such as file name, line number, and condition causing the failure. Stride provides a large set of these macros to validate a wide variety of validation scenarios.		Test cases are typically constructed leveraging a large set of available assertion macros. When failures occur, these macros automatically set test status and provide details to the test report such as file name, line number, and condition causing the failure. Stride provides a large set of these macros to validate a wide variety of validation scenarios.

Line 52:		Line 52:
	</source>		</source>

	= Extensive Parameter Support =		== Extensive Parameter Support ==

	Parameterized testing is key to reducing test code duplication. Constructor arguments, name-value collections, and host file remoting are all supported. Stride provides an easy way for passing and accessing these types of parameters, allowing customization of test behavior at runtime.		Parameterized testing is key to reducing test code duplication. Constructor arguments, name-value collections, and host file remoting are all supported. Stride provides an easy way for passing and accessing these types of parameters, allowing customization of test behavior at runtime.
Line 136:		Line 136:
	</source>		</source>

	= Test Implementation =		== Test Implementation ==
	Stride based tests are integrated with the existing build system enabling your software to be both fully ''functional'' and ''testable'' at the same time. The ''test logic'' is separated from the application source code and is '''not''' executed unless invoked via the Stride Runner. Any ''source instrumentation'' is only active when executing tests. The impact of built-in testability to the software application is nominal.		Stride based tests are integrated with the existing build system enabling your software to be both fully ''functional'' and ''testable'' at the same time. The ''test logic'' is separated from the application source code and is '''not''' executed unless invoked via the Stride Runner. Any ''source instrumentation'' is only active when executing tests. The impact of built-in testability to the software application is nominal.

Line 191:		Line 191:
	</source>		</source>

	= Works with Testspace =		== Works with Testspace ==

	Stride has been designed to fully leverage Testspace features such as test design, execution control, and test analysis. With Testspace, test content and status remain better organized and current results and progress are much easier to assess. Refer to [http://www.testspace.com Testspace] website for more details.		Stride has been designed to fully leverage Testspace features such as test design, execution control, and test analysis. With Testspace, test content and status remain better organized and current results and progress are much easier to assess. Refer to [http://www.testspace.com Testspace] website for more details.

Timd: /* Works with Testspace */

2015-07-07T18:16:02Z

Works with Testspace

← Older revision		Revision as of 18:16, 7 July 2015
Line 193:		Line 193:
	= Works with Testspace =		= Works with Testspace =

	Stride ~~have~~ been designed to leverage Testspace features such as test design, execution control, and test analysis. ~~Managing~~ test content and status ~~become~~ better organized and easier to assess ~~current progress~~. Refer to [http://www.testspace.com Testspace] website for more details.		Stride has been designed to fully leverage Testspace features such as test design, execution control, and test analysis. With Testspace, test content and status remain better organized and current results and progress are much easier to assess. Refer to [http://www.testspace.com Testspace] website for more details.

Timd: /* Test Points */

2015-07-07T18:09:00Z

Test Points

← Older revision		Revision as of 18:09, 7 July 2015
Line 102:		Line 102:

	===Test Points ===		===Test Points ===
	Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions / methods but rather verifies ''code sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.		Stride leverages ''source instrumentation'' to provide an additional validation technique called '''Expectation Testing''' that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions / methods but rather verifies ''code execution sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called '''Test Points''' -- developers strategically instrument the source under test.

	<source lang='c'>		<source lang='c'>

Timd: /* Test Doubles & Test Points */

2015-07-07T18:07:01Z

Test Doubles & Test Points

← Older revision		Revision as of 18:07, 7 July 2015
Line 92:		Line 92:

	// calling a routine that uses malloc(). checking handled null correctly		// calling a routine that uses malloc(). checking handled null correctly
	ret_code = ~~FuncThatUsersMalloc~~(42);		ret_code = FuncThatUsesMalloc(42);
	srEXPECT_EQ(ret_code, -1)		srEXPECT_EQ(ret_code, -1)

Line 135:		Line 135:

	</source>		</source>


	= Test Implementation =		= Test Implementation =