By default, the test harness uses the usmtest.properties file to determine the test cases and data. You can modify the usmtest properties file to configure tests for your custom connector or create a new usmtest properties file. The usmtest properties file must reside in the classpath for reading configuration values, but the SOI_HOME\SampleConnector\test\resources directory is the directory where files are included in the classpath by default. The property file must be present for the test harness to work correctly.
The following information must be defined in the properties file:
Defines the resources to use to perform the tests. The following parameters are included in the usmtest.properties file:
Define where the test harness retrieves data for the tests. The Sample connector usmtest.properties file contains separate properties for CIs (sample-cis.xml), alerts (sample-alerts.xml), and CI changes (sample-ci-changes.xml).
Defines the location and file name of the connector policy file that the test harness should use to test outbound operations.
Defines the location and file name of the connector policy file that the test harness should use to test inbound operations.
The Sample connector includes other configuration parameters that the test harness uses. For more information, see the SOI_HOME\SampleConnector\test\resources\usmtest.properties file.
Defines specific operations to test using specified data. The IFW calls the methods implemented by the connectors using filters, also called selectors. Selectors define what kind of data you want to retrieve or pass it as a parameter. You can define multiple test selectors, and each selector results in a call to a method identified by a selector. Each selector can have multiple properties (comma-separated key value pairs).The examples that follow describe some of the test cases included in the usmtest.properties file. For additional examples, see the usmtest.properties file.
Example: Testing the get() method
The test harness recognizes a selector for the get() method named "getSelector". You can run multiple instances of the test by appending a digit to the property name, such as getSelector1, getSelector2, and so on. The following example of a get() selector asks to return a ComputerSystem CI with an id value of 3 from the in-memory data repository of the Sample connector:
getSelector5="entitytype=Item,itemtype=ComputerSystem,id=3" getSelector5.expected.datafile=ComputerSystem_3.txt getSelector5.compare.ignorecase=true getSelector5.compare.locatorfields=MdrElementID getSelector5.compare.ignorefields=CreationTimestamp,LastModTimestamp, MdrProdInstance,UrlParams getSelector5.expected.result=true
The first line in the example instructs the test harness to look for a Computer System CI with an id value of 3. The second line specifies that the data returned by the get() method should look like properties and values listed in the ComputerSystem_3.txt file. The expected.result value of true indicates that the test is expected to be able to correctly find the item and that the actual returned data matches the expected data.
The locatorfields property lists properties that the test harness can use to speed up the lookup process, while the ignorefields property lists properties to ignore in the comparison between actual and expected data.
Example: Testing the create() method
Specifying selectors for create() and update() methods is very similar. The following example specifies to create the objects located in the SOI_HOME\SampleConnector\test\resources\SampleConnectorCreateValidDataFile.txt file:
create1.input.datafile=SampleConnectorCreateValidDatafile.txt create1.compare.ignorecase=false create1.compare.ignorefields=CreationTimestamp,LastModTimestamp,MdrProdInstance, UrlParams,MdrElementID,id,outfile,entitytype
Several CIs exist in the data file that the test harness is expected to create. Both the create() and update() methods return a data object that has been created or updated. The test harness compares the property values from the returned objects with the values specified as input. The test harness ignores the list of properties defined in ignorefields when comparing between actual and expected data.
Example: Testing the delete() method
Each delete() method test requires a selector that is expected to match only one CI or none at all. The following example deletes a CI that the test harness has created in a previous operation:
delete1="entitytype=Item,id=SampleConnector-0"
Example: Performing negative tests
You can create negative test cases that are designed to test how the connector responds to failure situations.
The following example of a get() test intentionally specifies an invalid entitytype:
getSelector13="entitytype=Negative.Test" getSelector13.expected.result=false getSelector13.expected.exception=true getSelector13.expected.exception.name=com.ca.ucf.api.UCFException
This test intentionally specifies an invalid entitytype of Negative.Test and defines the expected result as false. The test also specifies an exception that is expected to return.
The following example of a delete() test defines an invalid selector:
delete3="entitytype=Item,id=SampleConnector-NoNExIsTiNG" delete3.expected.result=false delete3.expected.exception=true delete3.expected.exception.name=com.ca.ucf.api.InvalidParameterException
|
Copyright © 2013 CA.
All rights reserved.
|
|