Doc:Sdk 4.0/taeguide/testimpl - Revision history

Bot: 33 revisions

2011-10-24T18:40:43Z

33 revisions

Jnanesh at 09:27, 25 March 2009

2009-03-25T09:27:33Z

Jnanesh: /* Multi-blade coordination */

2009-03-25T09:12:08Z

‎Multi-blade coordination

Jnanesh at 09:04, 25 March 2009

2009-03-25T09:04:54Z

Jnanesh: /* C TAE Interface */

2009-03-25T09:02:57Z

‎C TAE Interface

Ravi: /* Context */

2009-01-28T10:27:27Z

‎Context

Ravi: /* Context */

2009-01-28T10:26:05Z

‎Context

Ravi: /* Python TAE Interface */

2009-01-28T10:21:25Z

‎Python TAE Interface

Jnanesh: /* Summary */

2009-01-28T10:17:12Z

‎Summary

Jnanesh: /* Summary */

2009-01-28T10:15:40Z

‎Summary

← Older revision		Revision as of 09:27, 25 March 2009
Line 100:		Line 100:
	You can debug your own test by unlocking it as you would a normal application through the debug CLI (asp_console). The output of your test (i.e calls to clTestXXX functions) will be stored in /var/log/testresults.txt.		You can debug your own test by unlocking it as you would a normal application through the debug CLI (asp_console). The output of your test (i.e calls to clTestXXX functions) will be stored in /var/log/testresults.txt.

−	~~<br>~~

	==Examples==		==Examples==

← Older revision		Revision as of 09:12, 25 March 2009
Line 77:		Line 77:

	If your test must coordinate the activity of multiple blades then you must use the Python layer. There are rich set of APIs provided by TAE for this purpose.		If your test must coordinate the activity of multiple blades then you must use the Python layer. There are rich set of APIs provided by TAE for this purpose.
−	~~<br>~~

	=== Debug ===		=== Debug ===

@@ Line 1: / Line 1: @@
 === Create your model ===
-:Create a model using the OpenClovis IDE. Your model can use any redundancy model and contain any number of components and/or service groups. It can expect any number of blades. However, the most common configuration will be 2 system controllers and 0 or more payload blades. It would be best if your model supports this configuration (or fewer) and is capable of utilizing extra blades if they exist.
+Create a model using the OpenClovis IDE. Your model can use any redundancy model and contain any number of components and/or service groups. It can expect any number of blades. However, the most common configuration will be 2 system controllers and 0 or more payload blades. It would be best if your model supports this configuration (or fewer) and is capable of utilizing extra blades if they exist.
 === Add your tests ===
@@ Line 28: / Line 28: @@
 ==== Python TAE Interface ====
-: If you plan to implement your tests in a combination of C and Python by invoking some C functions from Python testcase, you must now add the TAE SOAP server and remotely callable functions to your model.  For an example of how to do this, please look at the "sysctrlcomp" component in the "bicTests" model in the "asptest" project [http://clovisforge.openclovis.org:8888/plugins/scmsvn/viewcvs.php/root/bicTests/src/app/sysctrlcomp/clCompAppMain.c?root=asptest&rev=946&view=markup here].  This component is untouched except for the addition of 2 remotely callable functions.  You must also add the "tae" subdirectory, as seen [http://clovisforge.openclovis.org:8888/plugins/scmsvn/viewcvs.php/root/bicTests/src/app/sysctrlcomp/?root=asptest here]. This is where you define and implement your RPC calls.  Finally, you must hook up the Makefiles, so that the "tae" subdirectory is build, as seen [http://clovisforge.openclovis.org:8888/plugins/scmsvn/viewcvs.php/root/bicTests/src/app/sysctrlcomp/Makefile?root=asptest&rev=1270&view=markup here].
+If you plan to implement your tests in a combination of C and Python by invoking some C functions from Python testcase, you must now add the TAE SOAP server and remotely callable functions to your model.  For an example of how to do this, please look at the "sysctrlcomp" component in the "bicTests" model in the "asptest" project [http://clovisforge.openclovis.org:8888/plugins/scmsvn/viewcvs.php/root/bicTests/src/app/sysctrlcomp/clCompAppMain.c?root=asptest&rev=946&view=markup here].  This component is untouched except for the addition of 2 remotely callable functions.  You must also add the "tae" subdirectory, as seen [http://clovisforge.openclovis.org:8888/plugins/scmsvn/viewcvs.php/root/bicTests/src/app/sysctrlcomp/?root=asptest here]. This is where you define and implement your RPC calls.  Finally, you must hook up the Makefiles, so that the "tae" subdirectory is build, as seen [http://clovisforge.openclovis.org:8888/plugins/scmsvn/viewcvs.php/root/bicTests/src/app/sysctrlcomp/Makefile?root=asptest&rev=1270&view=markup here].
-: Next you must implement your tests in Python, and have them call down to the C layer.  This information is best shown by example [[Doc:Sdk_4.0/taeguide/testimpl#Python_test_case | test_lint.py]]
+Next you must implement your tests in Python, and have them call down to the C layer.  This information is best shown by example [[Doc:Sdk_4.0/taeguide/testimpl#Python_test_case | test_lint.py]]
 ==== C TAE Interface ====
 * Any service group instances that run tests MUST be called tcSg<number>[Name]
-*: For example:
+* For example:
-*: tcSg001MessagingTest, tcSg034,
+* tcSg001MessagingTest, tcSg034,
 ** To run 2 service group instances simultaneously use tcSg<same number>[different name]
-**: For example:
+** For example:
-**: tcSg001a and tcSg001b, or tcSg005MsgClient and tcSg005MsgServer
+** tcSg001a and tcSg001b, or tcSg005MsgClient and tcSg005MsgServer
 =====Include and Library=====
@@ Line 76: / Line 76: @@
 ==== Multi-blade coordination ====
-:If your test must coordinate the activity of multiple blades then you must use the Python layer. There are rich set of APIs provided by TAE for this purpose.
+If your test must coordinate the activity of multiple blades then you must use the Python layer. There are rich set of APIs provided by TAE for this purpose.
 <br>
@@ Line 82: / Line 82: @@
 ==== Python TAE Interface ====
-: You can call your Python-to-C functions outside of the TAE with some very simple code.  In this example, assume that your RPC function is called "Log", and that you have set the MyPort variable to the TCP port of your TAE server (initialized in your component).  Your function will be magically created as a member of the WSDL.Proxy class, so in the example below it will be called in the line "soap.Log(...)".
+You can call your Python-to-C functions outside of the TAE with some very simple code.  In this example, assume that your RPC function is called "Log", and that you have set the MyPort variable to the TCP port of your TAE server (initialized in your component).  Your function will be magically created as a member of the WSDL.Proxy class, so in the example below it will be called in the line "soap.Log(...)".
 <pre>

@@ Line 99: / Line 99: @@
 ==== C TAE Interface ====
-:You can debug your own test by unlocking it as you would a normal application through the debug CLI (asp_console).  The output of your test (i.e calls to clTestXXX functions)  will be stored in /var/log/testresults.txt.
+You can debug your own test by unlocking it as you would a normal application through the debug CLI (asp_console).  The output of your test (i.e calls to clTestXXX functions)  will be stored in /var/log/testresults.txt.
 <br>
 ==Examples==

@@ Line 62: / Line 62: @@
 * If run independent of a Test Automation Environment (TAE) they will print out consistently formatted messages that can be analysed by scripts.  '''To stop the deluge of data, there is a mode that does not print test point successes'''
-* If run within a TAE, they will communicate state to the TAE.  '''So do not expect real-time performance'''
+* If run within a TAE, they will communicate state to the TAE.
 Note, some functions ask for formatted strings.  Please refrain from using newline or line feeds "\n" or "\l" since these functions will do formatting for you.  Also, do not use success or failure words, for example "Failed", "Pass", "Success", or "Ok", since the functions will also add this annotation.

← Older revision		Revision as of 10:26, 28 January 2009
Line 59:		Line 59:

	These functions will act differently depending on the context in which they are executed.		These functions will act differently depending on the context in which they are executed.
−
−	* If "CL_TESTING" is not defined at compile time, they will all be no-ops (not implemented yet). '''So, like assertions, do not put critical functions within a clTest macro!''' Of course, that only applies if you are writing a "normal" program that also has a test interface. If you are writing a test, then it will never be compiled without CL_TESTING defined.

	* If run independent of a Test Automation Environment (TAE) they will print out consistently formatted messages that can be analysed by scripts. '''To stop the deluge of data, there is a mode that does not print test point successes'''		* If run independent of a Test Automation Environment (TAE) they will print out consistently formatted messages that can be analysed by scripts. '''To stop the deluge of data, there is a mode that does not print test point successes'''

@@ Line 52: / Line 52: @@
 The module creates a hierarchy of tests;  a test, a test case, and a test point.  The "test" is started/stopped by clTestInitialize/clTestFinalize (clTestStart/End deprecated) and should precede and succeed all other clTest function calls.  In general, you'll call these functions once each in your program.  Next, within a "test", you are allowed to implement any number of "test cases".  A test case is whatever you want it to be, but generally think of it as a grouping based on configuration, load, or strategy.  To start/end a test case, use clTestCaseStart/End.  You can also use "clTestCase" if your test is a single line (like a function call) -- it's just syntactic sugar.
-Finally, individual predicates are called "test points".  Use the clTestXXX for these.  The basic function is clTest.  You essentially pass it a predicate (an expression that evaluates to a boolean) and it checks the truth of that predicate.  There is also a similar function that lets you also execute code if the test failed. This is mostly used to skip subsequent test points in a setup where each point requires that the prior succeed. Finally, you can claim that a test succeeded, failed or malfunctioned, without checking any predicate.
+Finally, individual predicates are called "test points".  Use the clTestXXX for these.  The basic function is clTest.  You essentially pass it a predicate (an expression that evaluates to a boolean) and it checks the truth of that predicate.  There is also a similar function that lets you also execute code if the test failed.  This is mostly used to skip subsequent test points in a setup where each point requires that the prior succeed.  Finally,  you can claim that a test succeeded, failed or malfunctioned, without checking any predicate.
-Malfunctioned?  What's that?  A "malfunction" occurs when initial conditions necessary to run the test were not met. For example, let's say you are running a messaging test. The test checks that messaging works between 2 processes on the same blade, and then checks between 2 blades. But what if it is run on a chassis with a single blade? In this case, the test could call TestMalfunction.
+Malfunctioned?  What's that?  A "malfunction" occurs when initial conditions necessary to run the test were not met. For example, let's say you are running a messaging test.  The test checks that messaging works between 2 processes on the same blade, and then checks between 2 blades.  But what if it is run on a chassis with a single blade?  In this case, the test could call TestMalfunction.
 =====Context=====

@@ Line 50: / Line 50: @@
 The module provides a set of functions that are useful while implementing regression tests.
-The module creates a hierarchy of tests;  a test, a test case, and a test point.  The "test" is started/stopped by clTestInitialize/clTestFinalize (clTestStart/End deprecated) and should precede and succeed all other clTest function calls.  In general, you'll call these functions once each in your program.  Next, within a "test" you are allowed to implement any number of "test cases".  A test case is whatever you want it to be, but generally think of it as a grouping based on configuration, load, or strategy.  To start/end a test case, use clTestCaseStart/End.  You can also use "clTestCase" if your test is a single line (like a function call) -- it's just syntactic sugar.
+The module creates a hierarchy of tests;  a test, a test case, and a test point.  The "test" is started/stopped by clTestInitialize/clTestFinalize (clTestStart/End deprecated) and should precede and succeed all other clTest function calls.  In general, you'll call these functions once each in your program.  Next, within a "test", you are allowed to implement any number of "test cases".  A test case is whatever you want it to be, but generally think of it as a grouping based on configuration, load, or strategy.  To start/end a test case, use clTestCaseStart/End.  You can also use "clTestCase" if your test is a single line (like a function call) -- it's just syntactic sugar.
 Finally, individual predicates are called "test points".  Use the clTestXXX for these.  The basic function is clTest.  You essentially pass it a predicate (an expression that evaluates to a boolean) and it checks the truth of that predicate.  There is also a similar function that lets you also execute code if the test failed. This is mostly used to skip subsequent test points in a setup where each point requires that the prior succeed. Finally, you can claim that a test succeeded, failed or malfunctioned, without checking any predicate.