Coded UI Automation Testing Walkthrough : Data Parameterization from CSV File

Now we will externalize data from a csv file in the following unit. Just create a csv file using excel sheet as is mentioned below. Though the file location is not at all a point of concern, yet we can avoid the same by keeping it in the project directory itself just in case the same project needs to be run from some other machine, the debug still works well.

Some Related posts on Coded UI Testing using VSTS :

Yeah we have created a csv file and have linked it up from the CodedUiTest file, via Test view. Right click to click its properies and follow up.

Now the automated script has been data driven in the true sense , and now if you change the userid and password in the csv file, the script will log you into the respective accounts.

Coded UI Automation Testing Walkthrough : Code Customization from Partial Class UiMap.cs

Now let us bring Code Customization to a higher level. If we can scroll down into the CodedUITest Calls file , then at the bottom of the page we can see a section of code relating to the term TestContext.  Do  keep in track that this very class is the base of all testing methods that are incorporated and brought to use by the Automation Namespace and methods in the complete CodedUi Automation Testing.

Some Related posts on Coded UI Testing using VSTS :

The TestContext is something that we will be bringing to an optimum use in our case when we will externalise our data from some sheet and also use a separate class file for code customization to bring in the Reusability feature in our Project.

Here in the code below we can see one more class file Namely UiMap.cs. This is another partial class file wherein we can use some code customization to bring in a sense of high degree of reusability. Here create one function under the partial class file as is shown under, with one parameter being passed  to it which is nothing but the TestContext instance  to which the current script relates to. The same can be seen in further screenshots. SO we have come to this new class file and from here on we shall be using this class file to create all custmized function calls. Hence now the Workflow will be CodedUiTest file -> Uimap.cs-> UiMap.designer.cs file.


In the second last screenshot we have introduced a New view namely the Test View , which is where from we run the Coded Ui Test methods,  All the methods are listed in this very View, Infact all the Methods can be organised at the overall level and the Namesapce level. This is how we have got the Test View, which needs to be refreshed at every Debug or run event. The updates made can be run only after refresh has been applied to the codes. So now we will be accessing all the methods from the TestView only.

Coded UI Automation Testing Walkthrough : Generated Code Analysis In CodedUiTest Class

This is now the look and feel of how the code for the Recorded Steps is organized under the TestProject. It is all a part of the added item namely CodedUiTest class under the default method name which is TestMethod1. Herein we will now analyze the control flow from this very class to the actual location of the Scripts recorded. The codes are actually present in another file called UIMap.Designer.cs wherein the definiton of the two function calls made from this class file is present. In this class two function calls are present , the ones we created during record time if you can remember from my earlier posts : LogIntoGmail, & ValiateLoginDetails.
 The first one has in it the recorded steps to loginto gmail account and the second one is the validation that the user logged into the account is as per the expected one.  Now when we want to look into the actual scripts during the record time, we can go into the UIMap.designer.cs file and visualize each and every event that occured while recording as is shown in below screenshots.

Some Related posts on Coded UI Testing using VSTS :

Well if you open the same file, it is pretty complex to figure out the definition for this very method name, but we can navigate to the same by a shortcut as is exemplified below, by right clicking and clicking go into definiton. In the following screenshots we have tried to use the genuine feature of OOPS programming, yeah non other than Polymorphism to override the values recorded during the Recording, Here what we have overridden is the username and password. We have just copied the code from designer file and pasted prior to the function call in the CodedUITest class file under the method name that is the scenario in an automated looks.Just copy the right side content value and paste it into this file and donot forget to add Uimap just after the this. field. So the code would look like this.UiMap.() , and so on. From hereon we will concentrate on customizing the codes generated during scripting via recording. For the first case that is username field we have no issues , but the second field is a password field and hence needs to be encrypted prior to script execution henceforth the this.uimap.() content is kept under PLayback.Encrypttext so that the password text is encoded before being put into the execution mode. By this we have started the most desired of all automation feature Data Independence of code execution but we have not externalized the data source yet and we shall be doing the same in our next post very soon. Do have a look through the below screenshots.

Coded UI Automation Testing Walkthrough :More On Generate Code For Assertion Steps

Intellisense has a very useful role to play . For example as has been explained below, in case you have recorded some steps but just missed out on to adding into your projects via code generation of the same, a pop up confirmation gets flashed if you wish to discard changes.

Some Related posts on Coded UI Testing using VSTS :

Henceforth  , it is all a pretty secured event.

Coded UI Automation Testing Walkthrough : Generate Code For Assertion Steps

Some Related posts on Coded UI Testing using VSTS :

Having Logged into the Gmail acoount what we generally need to check out for is whether we have logged into our account or not. In Testing terms it is called as a Validation of the Scenario and in the terminology of the Automation Testing it can referred as Checkpoint Validation. A very generic term is a Assertion . Here also we shall be introducing ourselves to the various types of Assertions that are available for use. Some of the common types being equals, contains, match, doesnotmatch,start with, ends with, et al.
Here I shall be using an assertion which is String Assert.Contains. which validates that the string as parameterized has its presence in the web page.

The following screenshot will be ample enough to clarify the flow that ought to be followed in order to put some verification checkpoints in the Automation scenarios.

Here as well we follow the same mechanism of creating the method to reflect the script codes association within the validation scenario. Suppose we name this method this time as ValidateUesrLogin, by default the method name that gets populated this time is AssertionMethod1. And same intelli sense facility is available here as well.

Coded UI Automation Testing Walkthrough : Generate Code For Recorded Steps

Some Related posts on Coded UI Testing using VSTS :

After having recorded the scenario, let us now concentrate on what to do next. To start with let us stop our recording after having logged into the Gmail Account. This can be done by  clicking on the last button in the pop up window, which indicates the Generate Code option. After clicking on the Generate Code button we get another small combo-box in which we can give the function modules which is signified by the current recorded set of scripts. Exempli gratia in the current context we have the scenario like Loginto gmail account, so we can give the name as LogIn method, but by default a name gets generated for the code and it in this case is RecordedMethod1. There is an intelli-sense associated with this very feature and if at all you have already created a method name it gets displayed as already available method and hence cannot be created, in only case wherein you want to remove the earlier code you can replace the earlier method content with the one that is generated this occasion. Normally these methods are practically named with the Test Case Id to which the scenario corresponds. Herein we will be naming it as LogIntoGmail and click Generate Code.

Let us have some screenshots that shall help you understand of the workflow in this regard.

Coded UI Automation Testing Walkthrough : CodedUI Test Builder Recorded Actions

By now we have got some insights into how we can start with Recording the flow within an application under test. Let us now delve into recording a scenario, a relatively simple one which almost all of us do in our day to day life : I guess the scenario is already known to you by now, yes it  is recording the flow of Logging into a Gmail account. I hope all of us agree that to be very simple is this very scenario as even as I explain through my future articles all shall be having a lot of understanding of the flow that needs to be covered herein.

         After having clicked the record button , as already discussed its color changes from red to Pause button white looks. What I have done to open the Internet explorer is Clicked in the Start Menu of the Desktop and cliked on Run button , then entered the site name [] which in our case is none other than IT Industry's God: No Prizes for guesses though yeah its Gmail. You might be guessing why is the red button in the picture even though I had clicked on record: It is because I had Paused the recording, or else the screen shot taking event would also had been recorded.

In the second screenshot as you can see the gmail home page is displayed and I have entered my username and password in the relevant fields. And then am clicking on the SignIn Button which navigates throught ot the gmail home page. Now I have just demonstrated the Use of the Second button from left as to visualize the steps that have been recording to make any layman understand actually what has been happening during the course of the recording.
You can easily figure out from the steps in the CodedUI Test Builder Recorded Actions:
Click the Start Button.
Click Run Button.
Select in combobox
Mouse hover about a co-ordinates which we did to take the mouse to the desired location.
Type email id
Type Password a hidden text field.
Then Finally click the SignIn Button.

Some Related posts on Coded UI Testing using VSTS :

Coded UI Automation Testing Walkthrough : Description of Record Buttons

        This is which will let you explore of how the UI looks like after we have added a Coded UI test item into our project. A class file gets generated with the C# code language and the small pop up comes at the bottom right corner of the screen. Going for the code details , it has three segments to be understood for the sake of good logical flow understanding of us all. The default name that the Coded UI test file has is CodedUITest1.cs. This is a class file, drilling down into the same gives us insight into the Constructor of this very class having the same name , Then we have one method name which by default has the the same starting name Prefixed to it hence the name being : CodedUITestMethod1.

So now we have three code segments with us, namely a class file having the same class name then a constructor and finally a Method name associated with it. Do keep intimated that  these are default named components and the same can be renamed as per our wish. Going at the top within the source file , we have the Namespace with which this very Class file is associated namely : TestGmail, if you can remember it is actually the same as the Project name we have associated with our current discussion. If you are aware of the hierarchy that the .Net framework follows is of Namespace, Assembly, Class, Method.

The bottom right corner of the screen lists a small pop up window which is actually the Recording tool and is the new addition that has added to great flexibility of this very tool to Testers and rapid Automation.It infact has associated with it three main buttons that are of preliminary interest to us, and one more button which is of important analysis interest. We will be discussing them all one at a time. And again while using them in our complete walkthrough of this very course shall let us have practical exposure to a profound extent. The first red coloured button is a recording button which when clicked turns into a Pause like button and instantly recording starts happening. Do remain informed that whatever you do with your machine after clicking this very button from red to pause will get recorded.
Is this a shortcoming , or do we have any option to control whatever we have recorded, at times things unknowingly which should not have been part of any recordings. Yeah we can control it in two ways, One is suppose we have some new mails in our outlook inbox and we wish to check the same , we can click on the Pause button(Record button in Record mode becomes Pause button) and check the same. Another case arises when we unknowingly out of some surprise just check the mails of "sweets at my desk", without actually clicking on the pause button.Do we have an alternative on the same, yes, we have one button just to the right of Record button, you can click on it to view the Recorded Steps.
 Since the content is in the simple english language , anybody can understand the same, and select and delete the recorded steps which are of no relevance to our business requirements.This is a flexible utility to be used in cases wherein we may have the privilege of enjoying chat with friends online in the communicator while record is on. Third from left is the "Cross Hair" button which is simple Validation button used to put some assertion on the system under test, by dragging it on the control content that needs to be validated. Do remember that it is the analog of the Checkpoint provision provided within the QTP tool. We shall definitely take this in detail. Fourth and final one is the "Generate Code " button , which as the name suggests is the code generator tool for all the Recording and the Validations that we have been putting on the system. Herein we have the option of checking the complete code that ought to be generated in order to make the VSTS playback the recorded scripts.Let us have a look of all these one at a time.

Some Related posts on Coded UI Testing using VSTS :