CodedUI tests project structure

Question

Can you please share the structure of your CodedUI test projects?

It would be interesting to see how you separate tests, helpers, UIMaps.

Answer 1

This is the way I do it. By no means the best or only way.

I have a static utilities class for basic functions and launching/closing the appundertest

public static class Utilities
{
    private static ApplicationUnderTest App;
    public static Launch()
    {
         try
         {
              App = ApplicationUnderTest.Launch(pathToExe);
         }
         catch (Microsoft.VisualStudio.TestTools.UITest.Extension.FailedToLaunchApplicationException e) {} 
    }
    public static Close()
    {
        App.Close();
        App = null;
    }
}

All of my *.uimaps are seperated bases on "pages" or "screens" of an application. This is sometimes codedUI screws up and your *.uimaps can break. Also worth mentioning all the uimaps contain are single actions on a page such as filling out a username for a log in or clicking a button.

I then have a NavMap class that holds all of the higher level "navigations" that I would do in my apps. It might be better to come up with some intricate structure, but I prefer to just list list methods in a static class

//you will need to include the uimap in a using statement
public static class NavMap
{
 public static void Login()
 {
  this.credsUIMap.EnterUsername();
  this.credsUIMap.ENterPassword();
  this.credsUIMap.ClickLoginButton();
 }

 public static void LogOut()
 {
  this.credsUIMap.ClickLogOutButton();
 }
}

Finally I have the codedUI test file where the tests formed

[TestClass]
public class Tests
{
    [TestMethod]
    public void TestMethod1()
    {
        NavMap.Login();
    }
    [TestMethod]
    public void TestMethod2()
    {
        NavMap.LogOut
    }

    [ClassInitialize()]
    public static void ClassInitialize(TestContext testcontext)
    {        
        Utilities.Launch();
    }

    [ClassCleanup()]
    public static void ClassCleanup()
    {        
        Utilities.Close();
    }
}

I Also do separate test files for different types of tests (positive, negative, stress, ...) Then I combine them in an orderedtest

Answer 2

I use multiple projects. One General containing common methods and common UIMaps for other projects (with the respective dependencies to General project).

And then I have a project for each desktop or web application that I want to automate. In projects: A UIMap for each window. Then, each test instances uimaps thats each are to be used. A ordertest grup of each test.

---

I can add the next example:

***I can't post images yet Example of my current test solution structure: https://i.stack.imgur.com/ekniz.png

The way to call an recorded action from a method test would be:

#using Application.UIMaps.Common_Application_UIClasses;
#using Application.UIMaps.Window_1_UIClases;

...

Common_Application_UI app_common = new Common_Application_UI();
Window_1_UI win1 = new Window_1_UI();

app_common.goToMenuThatOpenWindow1();

win1.setSomething("hello world!");
win1.exit();
app_common.exit();

Maybe this is not the best way of working but currently this is how I do.

Apologise for my english. I hope it inspire you.

Answer 3

I would highly recommend using something like Code First or CodedUI Page Modeling (which I wrote) to create abstractions over your UI in a highly testable way.

Even without these frameworks, you can easily write abstractions over your tests so that your test solution would look very similar to your main solution code.

I wrote a blog post about how this would look.

Typically, I would create a folder for each major workflow in the application and one for shared. This would be very similar to the MVC structure of your app. Each control in your app would become a Page Model in your testing project.

Web Project
 |
 |
 Views
   |
   --- Accounts
   |   |
   |   --- Create
   |   --- Manage
   |
   |
   --- Products
         |
         --- Search


Test Project
    |
    |
    --- Page Models
           |
           --- Accounts
                 |
                 --- ICreateAccountPageModel (interface)
                 ---  CreateAccountPageModel (coded ui implementation)
                 --- IManageAccountPageModel
                 ---  ManageAccountPageModel
           --- Products
                 |
                 --- ISearch
                 ---  Search

    |
    --- Tests
          |
          --- Accounts
                 |
                 --- CreateAccountTests
                 --- ManageAccountTests
          --- Products
                 |
                 --- SearchProductTests

The Page Models represent the page under test (or control under test if doing more modern web development). These can be written using a Test Driven approach without the UI actually being developed yet.

Create account view would contain username, password, and confirm password inputs.

Create account page model would have methods for setting the inputs, validating page state, clicking register button, etc.

The tests would test again the interface of your page model. The implementation would be written using Coded UI.

If you are using the MVVM pattern in your web site, your page models would end up looking very much like your view models.