Authoring Test Suites

The classes required for Test Suite authoring are located in the InRule.Repository assembly beneath the InRule.Repository.Regression namespace.

See Authoring a Simple Test Suite for Regression Testing for a sample

Most of the authoring Def classes inherit from the IdentifiedDefBase class, which simply provides them with a GUID identifier to assist persistence.  The DefBase also provides them with the following:

• Container property - Reference to the FolderDef container.
• Parent property - Reference to the parent collection or Def.
• GetAncestor<T> method - The first ancestor in the parent hierarchy matching the type T.

It is unlikely you will need to use these members for regular Test Suite authoring.  They are provided, along with the INotifyPropertyChanged interface, to assist the user interface.

API Documentation

Most members of each class are self-explanatory, so only the members of interest will be mentioned:

TestSuiteDef

• ActiveRuleApplicationDef - Use this property to associate a RuleApplicationDef with the Test Suite.  This should be the first step performed after creating the Test Suite.  The setter contains validation logic against existing Tests and Data States in the Test Suite so an InvalidRuleAppForTestSuiteException will be thrown containing the GUIDs of invalid Tests and Data States if the Rule Application’s schema does not match up.  Also, a MismatchedTestSuiteRuleAppGuidException will be thrown if the Rule Application’s GUID identifier does not match up with the one used when then Test Suite was authored.
• RootDataFolder - Use this property to add each new DataStateDef to the TestSuiteDef.  This should be performed in addition to assigning the DataStateDef to a TestDef.
• RootTestFolder - Use this property to add each new TestDef or FolderDef to the TestSuiteDef.
• Settings - Use this property to access the TestSuiteSettingsDef which should always exist for a TestSuiteDef.
• Create() - Use this method to create a new empty TestSuiteDef instance.  There is no public constructor on the TestSuiteDef to prohibit direct XML serialization; use the SaveAs() and Save() methods to achieve serialization via a persistence provider.
• LoadFrom() - Use this static method to load an existing TestSuiteDef from the specified persistence provider.
• Save() - Use this method to save the current TestSuiteDef with the persistence provider previously set using the SetPersistenceProvider() method.
• SaveAs() - Use this method to save the current TestSuiteDef with the specified persistence provider.

TestSuiteSettingsDef

There is a 1:1 relationship between the TestSuiteDef and the TestSuiteSettingsDef.  It represents the TestSuiteDef during serialization and contains settings for test execution, information Rule Application data, and the origin of a FileSystem or Catalog Rule Application when using the stand-alone version of the user interface.

• IncludeRuleExecutionLog - Use this property to indicate whether the test results should contain the RuleExecutionLog that was generated by the RuleSession when the test executed.
• IncludeXmlRuleTrace - Use this property to indicate whether the test results should contain the XML Rule Trace that was generated by the RuleSession when the test executed.  This should be used in conjunction with the TraceFrameTypes property on the RuleExecutionSettings.

TestDef

• Assertions - Use this collection to add AssertionDefs to the Test.
• DataStates - Use this collection to add DataStateMappingDefs to the Test.  The mappings connect EntityState Data States together to form a RuleSessionState.  If there is only 1 EntityState Data State, or a TestScenario Data State, this will be identified as the “-Root-“mapping.
• IsEnabled - The test execution will skip this test if this property is set to true.
• Overrides - Use this collection to apply DataStateOverrideDef instances to the test.  This allows either an individual field value to be changed in the initial state, or a collection member to be added.
• RootContext - Use this property to set the TestContextDef instance which represents the context (Entity or Independent RuleSet) on which the test will execute.  It is more common to pass this into the constructor of the TestDef.

TestContextDef

An instance of a TestContextDef should be generated from the static Create() factory method, rather than instantiating it with its constructor and settings all of its properties.

• Create() - Use this static method to create a new instance of the TestContextDef.  Its overloads allow either an EntityDef or RuleSetDef to be passed in, depending on the context required.
• RootContextName - Use this property to set the root context on which the test should execute.  This should match the RootEntityName of the root DataStateMappingDef’s DataStateDef.  The Create() method should automatically populate this.
• ExecutionType - Use this property to set the rule execution type (ApplyRules, Execute Explicit RuleSet, Execute Independent RuleSet).
• ExecuteRuleSetName - Use this property to set the name of the RuleSet to execute. (Does not apply to ApplyRules execution type)

DataStateDef

• DataStateType - Use this property to set the type of Data State: TestScenario or EntityState.
• RootEntityName - This should be set to the root Entity name that this DataStateDef represents.  If the DataStateType is TestScenario and an Independent RuleSet is the root, then use the name of the Independent RuleSet.
• RootEntityStateId - This should only be set when the DataStateType is TestScenario.  In certain scenarios the EntityStateId of the root Element ID, or Independent RuleSet is not 1. (e.g. Entity1::4)  If the DataStateType is EntityState or the TestScenario’s root EntityStateId is 1, you can safely leave this property unset, as it defaults to 1.
• StateXml - Use this string property to store the XML of either the TestScenario or the EntityState.  The TestScenario XML can be obtained by using the XmlSerializer.Serialize() on a RuleSessionState instance (accessible from RuleSession.State property).  EntityState XML can be obtained from the Entity.State.GetXml() method.

DataStateMappingDef

• ArgumentName - Use this property to set the name of either the Independent RuleSet Entity argument, or the name of a root-level temporary linked Entity field.
• DataState - Use this property to set the DataStateDef that should be mapped to the specified argument or field.

FolderDef

• FolderType - Use this property to set the type of folder. (TestFolder or DataFolder).  This should always be set to TestFolder as all Data States should exist at the root level of the TestSuiteDef’s RootDataFolder.
• Members - Use this collection to assign TestDefs to the FolderDef.  During the Add() method, the TestDef’s GUID is used to add a ReferenceToDef instance (instead of the TestDef itself) to the underlying collection.

ReferenceToDef

This class is used to represent a TestDef, DataStateDef or FolderDef in the hierarchy beneath a FolderDef.  This is because the default persistence provider implementation stores the Defs relationally in separate files (in a zip file) rather than hierarchically in a single file.  When iterating the FolderDef.Members collection, use the ReferenceToDef.EnsureReferencedDef() method to access the actual TestDef, DataStateDef or FolderDef.  Alternatively, use the ReferenceToDef.ReferencedDefId to pass into the TestSuiteDef.GetTest()/GetDataState()/GetFolder() methods, depending on the IsDataStateDef, IsTestDef, IsFolderDef properties.

DataStateOverrideDef

• DataOverrideType - Use this property to set the type of override. (SetValue or AddCollectionMember)
• TargetPath - Use this property to set the path to the state value to override using object-relational path (dot) notation. ( E.g. Entity1.Collection1(1).Field1 )
• Value - Use this property to set the value of the override.  This does not apply to the AddCollectionMember type.

AssertionDef

• AssertionType - Use this property to set the type of Assertion.  The AssertionType enum currently contains 29 different types of Assertion to choose from, e.g. FieldIsEqualToX, CollectionCountIsX.
• ExpectedValue - Use this property to set the string representation of the expected value of the Assertion.  Not all Assertions have an expected value, e.g. FieldIsNotNull.  The string representation should be in the culture-invariant format.  Dates should be stored as “#mm/dd/yyyy#”.
• ExpectedValueType - While the Business Language editor can determine the data type of the field from the Rule Application, SDK users should explicitly set this property to the correct data type.
• TargetElementPath - Use this setting to set the target of the Assertion using object-relation path (dot) notation. ( E.g. Entity1.Collection1(1).Field1 )

ZipFileTestSuitePersistenceProvider

This is currently the only persistence provider implementation which stores XML serialized TestSuiteSettingsDef, FolderDefs, TestDefs and DataStateDefs in individual files within a zip file.  SDK users need only pass the output path to its constructor and pass it to the TestSuiteDef.SaveAs() method.

To implement custom persistence providers, create a derived class that inherits from the TestSuitePersistenceProvider base class.