Version 8.0.2 |
Dependencies are a very powerful feature for handling setup and cleanup requirements for test cases automatically. The goal is to isolate test cases so that each one can be run independently without interfering with others. This is a very important requirement for things like testing arbitrary sub-sets of test cases, for example to re-test only failed tests, or during test-development where it must be possible to quickly run and debug any given test case.
'Dependency' nodes are used to implement advanced, automatic handling of setup and cleanup requirements for 'Test sets' and 'Test cases'. A detailed description of the 'Dependency' mechanism is given in section 8.6. This section focuses on formal requirements for the 'Dependency' node and its attributes. As 'Dependencies' are complex, they should be reused as much as possible. This can be done by grouping 'Test cases' with identical dependencies in a 'Test set' and have them inherit the 'Dependency' of the 'Test set'. However, this mechanism alone is not flexible enough, so a 'Dependency' can also be implemented just like a 'Procedure' and placed among the 'Procedures' of a test suite to be referenced from a 'Dependency reference' node. For this to work, the 'Name' attribute is mandatory and it also has a list of 'Parameter default values' that can be overridden in the referencing node. The 'Characteristic variables' of a 'Dependency' are part of its identity and play an important role in the dependency resolution mechanism. |
Contained in:'Test suite', 'Test set', 'Test case', 'Procedures', 'Package'.
Children: Zero or more 'Dependency references' on which the 'Dependency' is based, optional 'Setup' and 'Cleanup' nodes and an optional 'Error handler' followed by zero or more 'Catch' nodes.
Execution: Normally 'Dependencies' are executed only indirectly in the setup phase of a 'Test set' or 'Test case'. If a 'Dependency' node is executed interactively, the dependency stack is resolved as described in section 8.6.
Attributes:
Figure 41.9: 'Dependency' attributes |
A 'Dependency' is identified by its name, so you should assign a name with a meaning that is easy to recognize and remember.
Variable: No
Restrictions: Must not be empty or contain the characters '.' or '#'.
A separate name to be used for run log and report. This is useful to differentiate between multiple executions with potentially different values for the 'Characteristic variables'.
Variable: Yes
Restrictions: None
These variables are part of a 'Dependency's' identity. During 'Dependency' resolution as described in section 8.6 two 'Dependencies' are considered equal only if they are one and the same node and the run-time values of all their 'Characteristic variables' are identical. Additionally, the values of the 'Characteristic variables' are stored during the setup phase of the 'Dependency'. Later, when the 'Dependency' is rolled back, these settings will be temporarily restored for the cleanup phase.
'Characteristic variables' have the same value at a 'Cleanup' node as during the execution of the corresponding 'Setup' node - regardless of the value of the variables in the current test case.
Variable: No
Restrictions: None
Normally a 'Dependency' is only executed if it belongs to a 'Test case' node. 'Dependencies' in 'Test suite' or 'Test set' nodes are simply inherited by the 'Test case' descendants of these nodes. However, in some cases it is useful to resolve a 'Dependency' early, for example when the 'Dependency' provides parameters for a test run that are required to evaluate a 'Condition' of a subsequent 'Test case'. This can be achieved by activating this option.
Variable: No
Restrictions: None
Normally 'Dependencies' are only rolled back and their cleanup code executed as required by the dependency resolution mechanism described in section 8.6. In some cases it makes sense to force partial cleanup of the dependency stack immediately after a 'Test case' finishes. This is what the 'Forced cleanup' attribute is for. If this option is activated, the dependency stack will be rolled back at least up to and including this 'Dependency' .
Variable: No
Restrictions: None
Here you can define default or fallback values for the 'Dependency's' parameters (see chapter 6). Defining these values also serves as documentation and is a valuable time-saver when using the dialog to select the 'Dependency' for the 'Referenced dependency' attribute of a 'Dependency reference'. See subsection 2.2.5 about how to work with the table.
Variable: Variable names no, values yes
Restrictions: None
At the moment the 'QF-Test ID' attribute has no meaning for this type of node.
Variable: No
Restrictions: Must not contain any of the characters '\', '#', '$', '@', '&', or '%' or start with an underscore ('_').
These attributes cause a delay before or after the execution of the node. If a value is empty, the Default delay from the global options is used.
Variable: Yes
Restrictions: Valid number >= 0
Here you can enter a comment that explains the purpose of this node. This is the preferred way of documenting the test suite.
Note For detailed documentation, especially for 'Test set', 'Test case' or 'Procedure' nodes, this text area might not be the right place. There are many excellent editors that are much better suited to this task. The option External editor command lets you define an external editor in which comments can be edited conveniently by pressing [Alt-Return] or by clicking the button.
You can trigger special behaviors of some nodes using doctags, please see Doctags.
If you enter text in the comment field of a 'Component' node, the node will be considered as 'used' when you want to mark or delete unused components.
Variable: Yes
Restrictions: None
A 'Dependency reference' is simply a stand-in for a 'Dependency' defined in some
other place, typically a 'Package'. The name of the referenced 'Dependency' is
determined by its 'Name' and the 'Names' of its 'Package'
parents. These are concatenated with a dot ('.') as separator, starting with the
outermost 'Package' and ending in the 'Dependency's' name. Thus to reference a
'Dependency' named See section 25.1 about how to reference a 'Dependency' in a different test suite. |
Contained in:'Test suite', 'Test set', 'Test case' and 'Dependency'
Children: None
Execution: Normally 'Dependency references' are executed only indirectly in the setup phase of a 'Test set' or 'Test case'. If a 'Dependency reference' node is executed interactively, the referenced 'Dependency' is determined and the dependency stack resolved accordingly as described in section 8.6.
Attributes:
Figure 41.10: 'Dependency reference' attributes |
The full name of the 'Dependency', created from the 'Names' of its 'Package' parents and its own 'Name', joined by a dot. The "Select dependency" button above the attribute brings up a dialog in which you can select the 'Dependency' interactively. By selecting the "Copy parameters" checkbox you can adopt the 'Dependency's' 'Parameter default values' as parameters for the 'Dependency reference' node to save typing.
Variable: Yes
Restrictions: Must not be empty.
Normally there is only a single stack of dependencies, but in some cases, e.g. when mixing tests for independent SUT clients, it can be useful to have independent sets of dependencies for different parts of the test, so that resolving the dependencies for one part doesn't necessarily tear down everything required for a different part.
By setting the 'Dependency namespace' attribute of a 'Dependency reference' node you can tell QF-Test to resolve the target dependency in that namespace. The default dependency stack will be completely ignored in that case. If there is a dependency stack remaining from a previous dependency resolution in the same namespace it will be used for comparison instead, otherwise a new stack will be created. For an example please refer to Name spaces for Dependencies.
Variable: Yes
Restrictions: None
Normally a 'Dependency' is only executed if it belongs to a 'Test case' node. 'Dependencies' in 'Test suite' or 'Test set' nodes are simply inherited by the 'Test case' descendants of these nodes. However, in some cases it is useful to resolve a 'Dependency' early, for example when the 'Dependency' provides parameters for a test run that are required to evaluate a 'Condition' of a subsequent 'Test case'. This can be achieved by activating this option.
Variable: No
Restrictions: None
These variables override the 'Parameter default values' of the 'Dependency' referenced by this 'Dependency reference'. See subsection 2.2.5 about how to work with the table.
4.2+ In case you want to re-set the order of the parameters like they are sorted in the called dependency, you can select »Re-set parameter order«.
Variable: Variable names no, values yes
Restrictions: None
At the moment the 'QF-Test ID' attribute has no meaning for this type of node.
Variable: No
Restrictions: Must not contain any of the characters '\', '#', '$', '@', '&', or '%' or start with an underscore ('_').
These attributes cause a delay before or after the execution of the node. If a value is empty, the Default delay from the global options is used.
Variable: Yes
Restrictions: Valid number >= 0
Here you can enter a comment that explains the purpose of this node. This is the preferred way of documenting the test suite.
Note For detailed documentation, especially for 'Test set', 'Test case' or 'Procedure' nodes, this text area might not be the right place. There are many excellent editors that are much better suited to this task. The option External editor command lets you define an external editor in which comments can be edited conveniently by pressing [Alt-Return] or by clicking the button.
You can trigger special behaviors of some nodes using doctags, please see Doctags.
If you enter text in the comment field of a 'Component' node, the node will be considered as 'used' when you want to mark or delete unused components.
Variable: Yes
Restrictions: None
This node is just like a 'Sequence' except for its special place in a 'Dependency', 'Test set' or 'Test case' node. |
Contained in:'Dependency', 'Test set' or 'Test case'
Children: Any
Execution: The 'Variable definitions' of the 'Setup' are bound and its child nodes executed one by one. After the execution of the last child is complete, the variables are unbound again.
Attributes:
Figure 41.11: 'Setup' attributes |
The name of a sequence is a kind of short description. It is displayed in the tree view, so it should be concise and say something about the function of the sequence.
Variable: No
Restrictions: None
This is where you define the values of the variables that remain bound during the execution of the sequence's child nodes (see chapter 6). See subsection 2.2.5 about how to work with the table.
Variable: Variable names no, values yes
Restrictions: None
When a warning, error or exception occurs during a test run, the state of the corresponding node of the run log is set accordingly. This state is normally propagated to the parent node in a way that ensures that the error state of a run log node represents the worst of its child nodes' states. Using this attribute, the maximum error state that the run log node for a sequence will propagate, can be limited.
Note This value has no effect on the way exceptions
are handled. It only affects the error states of the run log nodes and
by that the exit code of QF-Test when run in batch mode
(see. section 1.7). It also has no effect on the
creation of compact run logs (see command line argument
-compact
). The node for a sequence in which a warning, error
or exception occurs is never removed from a compact log, even if the
error is not propagated due to the setting of this attribute.
Variable: No
Restrictions: None
At the moment the 'QF-Test ID' attribute has no meaning for this type of node.
Variable: No
Restrictions: Must not contain any of the characters '\', '#', '$', '@', '&', or '%' or start with an underscore ('_').
These attributes cause a delay before or after the execution of the node. If a value is empty, the Default delay from the global options is used.
Variable: Yes
Restrictions: Valid number >= 0
Here you can enter a comment that explains the purpose of this node. This is the preferred way of documenting the test suite.
Note For detailed documentation, especially for 'Test set', 'Test case' or 'Procedure' nodes, this text area might not be the right place. There are many excellent editors that are much better suited to this task. The option External editor command lets you define an external editor in which comments can be edited conveniently by pressing [Alt-Return] or by clicking the button.
You can trigger special behaviors of some nodes using doctags, please see Doctags.
If you enter text in the comment field of a 'Component' node, the node will be considered as 'used' when you want to mark or delete unused components.
Variable: Yes
Restrictions: None
This node is just like a 'Sequence' except for its special place in a 'Dependency', 'Test set' or 'Test case' node. |
Contained in:'Dependency', 'Test set' or 'Test case'
Children: Any
Execution: The 'Variable definitions' of the 'Cleanup' are bound and its child nodes executed one by one. After the execution of the last child is complete, the variables are unbound again.
Attributes:
Figure 41.12: 'Cleanup' attributes |
The name of a sequence is a kind of short description. It is displayed in the tree view, so it should be concise and say something about the function of the sequence.
Variable: No
Restrictions: None
This is where you define the values of the variables that remain bound during the execution of the sequence's child nodes (see chapter 6). See subsection 2.2.5 about how to work with the table.
Variable: Variable names no, values yes
Restrictions: None
When a warning, error or exception occurs during a test run, the state of the corresponding node of the run log is set accordingly. This state is normally propagated to the parent node in a way that ensures that the error state of a run log node represents the worst of its child nodes' states. Using this attribute, the maximum error state that the run log node for a sequence will propagate, can be limited.
Note This value has no effect on the way exceptions
are handled. It only affects the error states of the run log nodes and
by that the exit code of QF-Test when run in batch mode
(see. section 1.7). It also has no effect on the
creation of compact run logs (see command line argument
-compact
). The node for a sequence in which a warning, error
or exception occurs is never removed from a compact log, even if the
error is not propagated due to the setting of this attribute.
Variable: No
Restrictions: None
At the moment the 'QF-Test ID' attribute has no meaning for this type of node.
Variable: No
Restrictions: Must not contain any of the characters '\', '#', '$', '@', '&', or '%' or start with an underscore ('_').
These attributes cause a delay before or after the execution of the node. If a value is empty, the Default delay from the global options is used.
Variable: Yes
Restrictions: Valid number >= 0
Here you can enter a comment that explains the purpose of this node. This is the preferred way of documenting the test suite.
Note For detailed documentation, especially for 'Test set', 'Test case' or 'Procedure' nodes, this text area might not be the right place. There are many excellent editors that are much better suited to this task. The option External editor command lets you define an external editor in which comments can be edited conveniently by pressing [Alt-Return] or by clicking the button.
You can trigger special behaviors of some nodes using doctags, please see Doctags.
If you enter text in the comment field of a 'Component' node, the node will be considered as 'used' when you want to mark or delete unused components.
Variable: Yes
Restrictions: None
This node is just like a 'Sequence' except for its special place in a 'Dependency' (see section 8.6). |
Contained in:'Dependency'
Children: Any
Execution: The 'Variable definitions' of the 'Error handler' are bound and its child nodes executed one by one. After the execution of the last child is complete, the variables are unbound again.
Attributes:
Figure 41.13: 'Error handler' attributes |
The name of a sequence is a kind of short description. It is displayed in the tree view, so it should be concise and say something about the function of the sequence.
Variable: No
Restrictions: None
This is where you define the values of the variables that remain bound during the execution of the sequence's child nodes (see chapter 6). See subsection 2.2.5 about how to work with the table.
Variable: Variable names no, values yes
Restrictions: None
When a warning, error or exception occurs during a test run, the state of the corresponding node of the run log is set accordingly. This state is normally propagated to the parent node in a way that ensures that the error state of a run log node represents the worst of its child nodes' states. Using this attribute, the maximum error state that the run log node for a sequence will propagate, can be limited.
Note This value has no effect on the way exceptions
are handled. It only affects the error states of the run log nodes and
by that the exit code of QF-Test when run in batch mode
(see. section 1.7). It also has no effect on the
creation of compact run logs (see command line argument
-compact
). The node for a sequence in which a warning, error
or exception occurs is never removed from a compact log, even if the
error is not propagated due to the setting of this attribute.
Variable: No
Restrictions: None
At the moment the 'QF-Test ID' attribute has no meaning for this type of node.
Variable: No
Restrictions: Must not contain any of the characters '\', '#', '$', '@', '&', or '%' or start with an underscore ('_').
These attributes cause a delay before or after the execution of the node. If a value is empty, the Default delay from the global options is used.
Variable: Yes
Restrictions: Valid number >= 0
Here you can enter a comment that explains the purpose of this node. This is the preferred way of documenting the test suite.
Note For detailed documentation, especially for 'Test set', 'Test case' or 'Procedure' nodes, this text area might not be the right place. There are many excellent editors that are much better suited to this task. The option External editor command lets you define an external editor in which comments can be edited conveniently by pressing [Alt-Return] or by clicking the button.
You can trigger special behaviors of some nodes using doctags, please see Doctags.
If you enter text in the comment field of a 'Component' node, the node will be considered as 'used' when you want to mark or delete unused components.
Variable: Yes
Restrictions: None
Last update: 12/4/2024 Copyright © 1999-2024 Quality First Software GmbH |