Coded UI Test: Convert Normal CUIT to Data Driven CUIT using Visual Studio 2010
Posted by: Gouri Sohoni
in Category Visual Studio, VSTS & TFS
Abstract: In this article, we will discuss how a normal Coded UI Test can be converted to Data Driven Coded UI Test in Visual Studio 2010. We will also discuss various data sources which can be used to provide data to the test method.
In the previous articles, we have discussed How to create CUIT by using CUIT Builder, How to create CUIT by converting manual to automated and Variations and Editing with CUIT. In this article, we will discuss how existing CUIT can be converted to take up data from any Data Source.
We will use existing CUIT which records actions for Windows Application. This is a part of Employee Management System’s Windows functionality. The HR person can add, modify and view employees in the organization. This application involves Login form which requests for User Name and Password. After a successful login, the HR can view the Employee’s record by entering EmployeeId. This id is given as a constant value (while recording) which we will pick up from various data sources, by adding the DataSource attribute to the test method.
Following are the methods created for the application under test.
Let us see how to data bind the Coded UI Test step by step.
Step 1: Select the CUIT named CUITWinApp from the Test View. Test View can be seen from Test – Windows and Test View Option. Select the method and select properties for the method, Click on the ellipse button for the property of Data Connection String
Step 2: Clicking on the button automatically starts the New Data Source Wizard for us where we can select Data Provider from a table, .csv file or .xml file as can be seen from the screenshot.
Step 3: Let us connect to a table from SQL Server with following Employee data in it:
Step 4: Select Database from the wizard and click on the Next button. Click on ‘New Connection’ and provide the following details.
Step 5: Now what remains to select is the table name which is having the required data.
Step 6: Now that the data binding is done, we can see the attributes added to the test method.
Observe the TestMethod attribute remains as it. Along with it, we can view the DataSource, DataAccessMethod getting added. The provider complete connection string with table name and the data access method can be seen. The data access method can either be sequential or random.
Now when we execute this CUIT, it will get executed as many number of times as there are records in the table (3 in our case). The data access can also be random. The DataRow from TestContext can point to the column number as shown or the column name in quotes.
Step 7: Now that the connection string is provided, we will have to specify that the data is coming from the Data Source and not as a constant value which was recorded with CUIT Builder. With every method added using CUIT Builder, a method with “Params” as ending word gets automatically added. This is the method which will be helpful. We will need to make the following change as shown below. With this code snippet, we can view the column name instead of column index.
Step 8: Now we will execute the CUIT from the Test View after refreshing the view. The Test Results window is as shown below:
The details of test run are as shown below:
Here all the 3 iteration can be seen as passed.
Step 9: We will now create a .csv file and repeat the process. We will have to first add the file to the solution and provide data to it. We will add a New Item to the solution, select text file, specify the extension as .csv and enter the following data
Step 10: Select the method in Test View and change the Data Connection String property. The data source wizard now is connected to the .csv file
Step 11: Once the connection string is changed, we need to change the value for the column name in the code. Here instead of the column name, the index is used. The complete code snippet looks like the following:
The DataSource attribute now points to the .csv file and also the name of the file can be seen.
Step 12: On executing ,we get result as failed, as one of the record entries is not available in the table. The detailed test result displays that the test failed for one record
Step 13: Similarly the data can be obtained from an XML file after creating the file and adding it to the current solution. We just need to change the data connection string for the xml data later.
Conclusion: In this article, we discussed how a normal Coded UI Test can be converted to Data Driven Coded UI Test. We also discussed various data sources which can be used to provide data to the test method.