Data Driven Testing Tutorial Part 2
In the previous installment of this tutorial, you learned how to create data sources and use the DDT object's DriveMethod property to enter data in an application. But what happens when your application changes and you have more data to enter? Do you just keep adding on to your original spreadsheet and the Logger method? You could, but that's going to become unwieldy quickly, especially if your application is going to ultimately have a lot of fields. Let's say that the Contact Builder application has been updated to include personal information, such as birth date, marital status, spouse's name, and any childrens' names. This information is contained on a new tab in the program, as shown below:
You decide that it will work best to keep this information in a separate worksheet of your Excel input file, so you create a worksheet called PersonalInfo with one column for each new field. The end result looks like this:
Now, we need to modify our automated script to enter this new information. We'll start by adding a second DDT.ExcelDriver object that references the PersonalInfo worksheet. Then we'll specify the Name property for both of the ExcelDrivers. The resulting code looks like this:
In the previous installment, we made use of the DDT.CurrentDriver property. This allowed TestComplete to access the DDT object that was last loaded into memory. Now that we have two DDT objects, we don't want to only reference the last one created, as that will only allow us to access the one containing personal data. This is why we're specifying the Name property of the DDT object. We'll change the code in the Logger method so that it references the DDT objects by this name, thus allowing us to use more than one data source. We'll also change the ColumnName property so that it uses the actual name of the column in the spreadsheet, rather than the column's index value. The updated Logger method looks like this:
Now we need to write some code to enter data on the Personal Data tab. We could either append this code to the Logger function, or we can create a new function that is used specifically for the Personal Data tab. A good rule of thumb for any kind of automation is always to make your code as modular as possible, so we'll make a new function called enterPersonalData.
OK, now we have code that correctly enters both the standard contact information, and the contact's personal data. However, you'll notice that the Logger method contains code to click the OK button and validate the appropriate text is displayed. Because of this, our script will never get the chance to enter information on the Personal Data tab. As such, our next step is to restructure the test method so that information on both tabs is entered before the OK button is pressed and any validation takes place. We'll start by creating a new method called populateContactInfo. This method calls both the Logger and enterPersonalData functions. Additionally, we'll move the lines of code that click OK and verify the message text from the Logger function into a second function called clickOKAndValidate. The code looks like this:
The last change we need to make is in the test function. Instead of calling Unit1.Logger in the inputData.DriveMethod, we're going to call populateContactInfo. By doing this, we'll call the Logger method, the enterPersonalData method, and the clickOKAndValidate method for each row of our input worksheet. The complete code for this project is at the end of this tutorial.
Keeping your input data separate from your test code is what data driven testing is all about. By keeping your code modular, and your input outside of your scripts, you can ensure a flexible, effective automation solution that will be easy to maintain and debug.