The XML Config File
Your configuration file should now look like TestDriver.xml. The following are all the possible configuration parameters you can set for your own test scenarios:
Within the context of <TestDrivers>, you can have as many TestDriver classes as you want using the <TestDriver> tag.
<TestDriver Id="1" Class="example.StdMgrTestDriver" Method_Dependency="Yes">
For a detailed description of the TestDriver attributes, see the TestDriver Attribute Descriptions table.
TestDriver Attribute Descriptions
||Fully qualified name of the TestDriver|
||Unique identifier within the scope of <TestDrivers>|
||If Yes, all the methods listed as part of the TestDriver will be executed sequentially.|
If No, each method will be executed in its own thread.
Within the context of <Methods>, you can list all the methods that are part of the TestDriver class using a <Method> tag.
<Method Name="testAdd" Method_Id="ADD" Participate="YES" Return_Type="boolean">
For a description of the Method attributes, see the Method Attribute Descriptions table.
Method Attribute Descriptions
||Name of the method in the TestDriver|
E.g., testAdd, testFindStudent, etc.
||Unique identifier within the scope of <Methods>|
E.g., ADD, FIND
||If set to YES, the method participates in the test run.|
By default, all methods participate.
||The return type of the method.|
By default, this value is "void."
||Order in which the methods should be executed.|
This will be used when the Method_Dependency flag is set to Yes.
||If you want your method to be run on more than one thread, set the number_of_threads.|
E.g., 1, 2, etc.
||Setting this value to YES makes the method run as a top-level method. You can set up a dependency order between various methods; for example, you can say Method2 should be executed after Method1. In this case, Method1 will be a parent method and Method2 will not.|
By default this value is NO and hence you must set this value to YES if you want the method to participate in the test run (even when there are no dependencies).
||Referring to the Is_Parent description above, the Next_Method_Id value for Method1 will be the Method_Id value of Method2. This tells jDefend that Method2 has to be executed after it executes Method1.|
Within the context of <Arguments>, you can list all the arguments that a Method accepts using the <Argument> tag.
A simple argument (testFindStudent scenario) looks like this:
<Argument Num="1" Type="String" VALUE="DolphinNose" />
A complex argument (testAdd scenario) looks like this:
<Argument Num="1" Type="example.Student" VALUE="CustomType" Id="StudentX" />
For a description of the Argument attributes, see the Argument Attribute Descriptions table.
Argument Attribute Descriptions
||Indicates the argument order.|
If Num is 1, the method accepts the argument type as the first argument.
E.g., 1, 2, etc.
||Indicates the type of argument.|
This attribute supports all simple data types. For complex data types, this would be a fully qualified class name such as java.util.Vector.
E.g., String, int, java.util.Vector, Student
||Indicates the value to be passed. |
E.g., DolphinNose, for the method testFindStudent.
If the Type is a user-defined type or complex data type, Value should be set to CustomType.
||A unique Id for the given Argument.|
This is required only for CustomTypes.