Whether CodedUI scripting is mentioned across everyone’s post, from the word of mouth, or any other source, it is at best known to be a means of testing what is already built. In case it is a web application, we need a running instance of the same on the desktop, and we need it to be hosted and accessible from some server. What if you had the flexibility of running the application to be tested from within your scripts and closing them when the script is done? We stumbled across this problem when we were trying to implement an advanced level of Automation Testing infrastructure for our own controls, and it was something that baffled us, albeit only until we came up with a very direct and easy to implement approach. The best utility for this approach is removal of dependence on an external source other than your test project to run the actions on. There is no need to manually check if the test application is actually running everytime or not. Did any exception cause the closure of test instance thereby causing all the following tests to fail as well? We implemented this across all the technologies so we essentially could cut short the practice of Build – Deploy – Test to just Build – Test, re rendering the words -One small step for CodedUI, which is one giant leap for complete automation testing.

Basic Approach

Here’s how we did the invoking of the application instance:

1. Call the application instance using Process.Start(). Make sure to put these in a Try- Catch block so that we know if the application did not start at the beginning of the script execution.
2. Put script steps in another Try-Catch block after this, and put in plausible assertions
3. In the “Finally” block of the sample invoking Try-Catch, kill the process hosting the application, or you can use any other code to effectively close the application instance.

For Winforms Application

Below is the code for implementing the same in C#,

public void open_application()  
{  
    try  
    {  
       System.Diagnostics.Process.Start(@"Path of the sample exe to be started");  
    }  
    catch (Exception ex)  
    {  
       Assert.Fail(ex.Message);  
    }  
}  

public void close_application()  
{  
  try  
    {  
      for (int i = 0; i < 2; i++)  
       {  
         foreach (Process p in System.Diagnostics.Process.GetProcesses())  
          {  
            if (p.ProcessName.Contains("SampleName"))  
             {  
               System.Threading.Thread.Sleep(500);  
               p.CloseMainWindow();  
             }  
          }  
       }  
    }  
  catch (Exception ex)  
  {  
      Assert.Fail(ex.Message);  
  }  
}

For Web Applications

If the application is a WebApplication, then we would need it to be hosted on IIS, so as to run and open the different webpages. This again can be done by executing the “WebDev.WebServer” command prompt utility provided with VS2010. It follows a simple syntax to host a web application on the local IIS (That needs to be there on the test machine for this kind of approach). WebDev.WebServer40.Exe /port: /path: /vpath: This is how the above implementation looks in the code :

public static void dep_website()  
{  
  string filename1 = @"C:\\Program Files (x86)\\Common Files\\microsoft shared\\DevServer\\10.0\\WebDev.WebServer40.EXE";  
  string args1 = string.Format(“/port:<portnumber> /path:<actual path of the webapplication> /vpath:<path that you would want on the webserver>");  
  Process p1 = new Process();  
  p1.StartInfo.FileName = filename1;  
  p1.StartInfo.Arguments = args1;  
  p1.StartInfo.CreateNoWindow = true;  
  p1.StartInfo.UseShellExecute = false;  
  p1.Start();  
  pName = p1.ProcessName;  
}  
public static void close_website()  
{  
 Process[] list1 = Process.GetProcesses();  
 foreach (Process p in list1)  
  {  
    if (p.ProcessName == pName)  
      p.Kill();  
  }  
}

Although the above approach simply runs the test samples, it causes an overhead on the scripts being run. This approach is always open to more customizations and the discretion of the one implementing.