Active Tags in TagGroups control how MxSuite tests run. In regressions, they can cause a select subset of scenarios to run, they can change the effective value of constants, and reactive code can be implemented to respond to them. Tags can be activated and cleared in several ways. It is important to understand the conventions.
A simple example might be a Tag Group called EquipmentLevel, with tags Economy and Luxury. With this concept you can consider making tests that could be used for both the Economy and Luxury configurations. When you invoke MxSuite, you can assign EquipmentLevel to Luxury thereby requiring that all configurable tests that respond to that Tag Group run in the Luxury configuration. You can assert Tags in Groups on the command line, from COM, or in the Project Settings. You can also make such assertions programmatically as reactive Scenarios and TestCases code executes.
•You can have zero or more TagGroups in a Project. To be useful, each TagGroup will have one or more Tags in it.
•For each TagGroup, you can activate zero or more of the Tags in the group. Activating means the Tag is ‘switched on’.
oOne limitation to this is if the TagGroup is implicitly mutually exclusive. Then only one Tag in the group can be active. It is a mutually exclusive Group if it is used to select between alternate values of a Constant.
•In the Project Settings of MxSuite, you can define Tags and TagGroups.
oA tags panel exists for viewing and changing Tag states
oThese states are persistent (the Tags get reactivated as the project is opened).
oImporting/Exporting tag states to a file is also done from the panel.
•Tags can be similarly modified via COM, from the Command Line, or in Reactive Code.
oProject - as specified in the .mxtags file
oSession - as displayed in the GUI
oScenario - set in the Scenario's reactive code
oTestCase - set in the TestCase's reactive code
•Tag states are inherited from the next higher level. For example, a TestCase inherits the tag states from the Scenario that runs it.
•Changes made at one level (for example in a Scenario's reactive code) revert to the previous state when the test returns to the higher level (for example, when the Scenario terminates). In other words, higher levels do not inherit tag states from lower levels.
•In Reactive Code for each Tag you can:
oTest to see if it is Active.
oRevert (clear) Active Tags:
•If in a Reactive TestCase code you make a call to Revert() tag states, then only the changes made in that TestCase are cleared.
•If in a Reactive Scenario code you make a call to Revert() tag states, then the Tag assertions made in that Scenario and any of the TestCases that it invoked will be cleared.
•Following the initial Tag activations when the project is opened, subsequent Tag activations are cumulative, for example:
oIf the Project Settings activate Tag1 in Group A and COM activates Tag2 in Group A, then both will be activated (unless the Group is implicitly mutually exclusive, in which case only Tag2 will remain active).
oIf a Scenario's Reactive Code Asserts Tag1 in Group A and the Reactive Code of a TestCase (that the Scenario invoked) Asserts Tag2 in Group B, then both Tags will be active for that TestCase.