Data-drive your ALM tests

Drive data through your test by adding ALM input parameters to any OpenText Functional Testing for Developers test that is run from ALM. Then you can set up test sets that run your tests in a variety of configurations, each running multiple iterations.

Prerequisites for data driving tests

  • Install the 32-bit version of Microsoft Access Database Engine 2016 Redistributable.

Back to top

Set up data-driving steps in OpenText Functional Testing for Developers

In OpenText Functional Testing for Developers:

  1. Open your test project, or create a new one as described in Create a testing project or module.

  2. Configure your test script to retrieve ALM data.

    1. In your NUnit project, change the [Test] attribute (above the test method) to:

      • NUnit 2: [TestCaseSource("ALM")]
      • NUnit 3: [TestCaseSource("ALMStatic")]

    2. Define meaningful test method argument names. They must be identical to the to the test parameter names that you define in ALM.

      [TestCaseSource("ALM")]
public void Test1(string MyParam1, string MyParam2)
{
	...
	... 
}

    3. Create your test content as with any other OpenText Functional Testing for Developers test.

    4. Build the project to create a test .dll.  

    The HTML report of a data driven OpenText Functional Testing for Developers test run includes one node for each iteration.  Each node's label displays the actual values of the parameters for that iteration.

    1. In OpenText Functional Testing for Developers:

      In your MSTest project, after [TestMethod], add the [DataSource ("ALM")] attribute to the test method.

      Access the test parameters using the TestContext.DataRow["valueA"] statement.

      For example: 

      [TestMethod]
[DataSource("ALM")]
publicvoid TestAlm()
{
	var valueA = Convert.ToString(TestContext.DataRow["valueA"]);
	var valueB = Convert.ToString(TestContext.DataRow["valueB"]);
	Verify.AreEqual(valueA, valueB);
}

    2. (Optional) Add the [Parameters( <parameter_names_list> )] attribute to the test method to:

      • Provide test’s parameter names for the Test Export tool (see below)
      • Customize the test name appearance in the OpenText Functional Testing for Developers run report (see below)

      For example:

      [TestMethod]
[DataSource("ALM")]
[Parameters("valueA", "valueB")]
publicvoid TestAlm()
{
	var valueA = Convert.ToString(TestContext.DataRow["valueA"]);
	var valueB = Convert.ToString(TestContext.DataRow["valueB"]);
	Verify.AreEqual(valueA, valueB);
}

      Note:  

      • If the Parameters attribute is absent, all values of the current DataSource row will appear in the suffix of the Test Case name.
      • If the Parameters attribute is present and contains the parameter names, only the values of those parameters will appear in the suffix of the Test Case name.
      • If the Parameters attribute contains names that are not in the DataSource row, N/A will appear in report.

    3. Build the project to create a test .dll.

    1. In your JUnit project, use the OpenText Functional Testing for Developers JUnit Data-Driven Test Case class template to create the OpenText Functional Testing for Developers JUnit test class with ALM data-driving support.

      Select New > OpenText Functional Testing for Developers > OpenText Functional Testing for Developers JUnit Data-Driven Test Case and fill in the required fields in the wizard.

    2. Define the parameters using one of the following methods:

      • (Recommended): Use the @Parameter annotations provided with the JUnit Data-Driven Test Case template

        In the Data-Driving section of the template, add @Parameter(n) attributes for each parameter, each with an incremental index value, starting with 0.

        Note: Always use the unique running number as an argument of the @Parameter annotation.

        Give the parameters names that will be logical when they appear in ALM. The first parameter appears as your first parameter in the OpenText Functional Testing for Developers test in ALM, and so on.

        For example:

        @Parameter(0)
public String MyParamA;
@Parameter(1)
public String MyParamB;

      • Add a parameterized class constructor with the @ALM annotation

        1. Add an import line for the datadriving.ALM package.

          For example:

          import com.hp.lft.unittesting.datadriving.ALM;

        2. Delete or comment out the @Parameter lines provided with the JUnit Data-Driven Test Case template:

          //@Parameter(0)

          //public String MyParamA;

//@Parameter(1)
//public String MyParamB;

        3. In its place, paste the following code, and replace the MyParam* names with your actual parameters. 

          private String MyParamA;
private String MyParamB;

public DataDrivenTest1(@ALM(parameter = "MyParamA") String paramA, @ALM(parameter = "MyParamB") String paramB){
	this.MyParamA = paramA;
	this.MyParamB = paramB;
}

          For example:

          private String username;
private String password;

public DataDriven(@ALM(parameter="username") String param1, @ALM(parameter="pw") String param2){
	this.username = param1;
	this.password = param2;
}

    3. Customize the argument of the @Parameters annotation provided in the template. This name defines the node title that will be displayed for each iteration in the HTML run results report.

      For example: 

      @Parameters(name = "iteration: {index}; FirstName={0}")

      where the FirstName parameter is defined in the class as @Parameter(2) (or as the 3rd parameter using the @ALM annotation).

      The results would then look something like this:

    4. Create your test method content in the @Test section as with any other OpenText Functional Testing for Developers test.

    5. Export the project to JAR.

    1. In your TestNG test class, add the dataProvider="ALM" argument to the @Test annotation of test method:

      @Test(dataProvider="ALM")

    2. (Optional) Use the @Parameters({ <parameter_names_list> }) annotation to map the ALM test parameter names to the method arguments.

      • Each name defined in the parameter list must be identical to the parameter name defined in ALM

      • Each name defined in the parameter list must be mapped to the method argument by order. The first method argument must be mapped to the first @Parameters argument, and so on. The method argument names can be voluntary.

    3. Export the project to JAR.

    Example:

    @Test(dataProvider="ALM")
@Parameters({ "x", "y" })
public void test(String a, String b) throws Exception { 
	Verify.areEqual(a, b, "MyVerify", String.format("%s == %s ?", a , b));
}

Back to top

Set up ALM for data driving

  1. Define the parameters in ALM. You can do this in any of the following ways:

    OpenText Functional Testing for Developers Test Export tool

    Export the test methods to an XML file and then import them into ALM. The defined parameters in each test method are imported into ALM together with the test methods. For details, see Import tests into ALM
    Define the parameters in ALM manually

    In ALM, in the signature of each LEANFT-TEST test, in the Parameters tab, define the set of input parameters to use. The parameters must be defined exactly as they are defined in your OpenText Functional Testing for Developers test methods. For details, see Manually create LEANFT-TEST tests in ALM.

  2. Create test configurations and map parameters in ALM

    1. In ALM, select your OpenText Functional Testing for Developers test.

    2. In the Test Configuration tab, create static or dynamic configurations, and customize each configuration as needed.

      Static data configuration allows supplying fixed data directly from the data grid within the test configuration.

      Dynamic data configuration allows supplying the dynamic data from an external Microsoft Excel file by uploading it as a test resource into ALM and associating it with the test configuration.

      • For each dynamic configuration, you can optionally override the default data source defined for the test and/or customize the rows to use from the table.

      • Filtering by value is not supported for OpenText Functional Testing for Developers tests. Any filter settings are ignored.

      Tip: Alternatively, create a static configuration which enables you to provide fixed data for a run with a single iteration.

      For more details about setting up static and dynamic data configurations in your test configuration, see the ALM Help Center.

Back to top

See also: