Coded UI tests

Unit tests typically work by calling methods in the interface of the code under test. However, if you have developed a user interface, a complete test must include pressing the buttons and verifying that the appropriate windows and content appear. Coded UI tests (CUITs) are automated tests that exercise the user interface. See the MSDN topic Testing the User Interface with Automated Coded UI Tests.

How to create and use coded UI tests

Create a coded UI test

To create a coded UI test, you have to create a Coded UI Test Project. In the New Project dialog, you’ll find it under either Visual Basic\Test or Visual C#\Test. If you already have a Coded UI Test project, add to it a new Coded UI Test.

In the Generate Code dialog, choose Record Actions. Visual Studio is minimized and the Coded UI Test builder appears at the bottom right of your screen.

Choose the Record button, and start the application you want to test.

Recording a coded UI test

Perform a series of actions that you want to test. You can edit them later. You can also use the Target button to create assertions about the states of the UI elements. The Generate Code button turns your sequence of actions into unit test code. This is where you can edit the sequence as much as you like. For example, you can delete anything you did accidentally.

Running coded UI tests

Coded UI tests run along with your other unit tests in exactly the same way. When you check in your source code, you should check in coded UI tests along with other unit tests, and they will run as part of your build verification tests.
Tip: Keep your fingers off the keyboard and mouse while a CUIT is playing. Sitting on your hands helps.

Edit and add assertions

Your actions have been turned into a series of statements. When you run this test, your actions will be replayed in simulation.

What’s missing at this stage is assertions. But you can now add code to test the states of UI elements. You can use the Target button to create proxy objects that represent UI elements that you choose. Then you write code that uses the public methods of those objects to test the element’s state. Extend the basic procedure to use multiple values You can edit the code so that the procedure you recorded will run repeatedly with different input values. In the simplest case, you simply edit the code to insert a loop, and write a series of values into the code.

But you can also link the test to a separate table of values, which you can supply in a spreadsheet, XML file, or database. In a spreadsheet, for example, you provide a table in which each row is a set of data for each iteration of the loop. In each column, you provide values for a particular variable. The first row is a header in which the data names are identified:

Flavor                     Size
Oatmeal                   Small
Herring                    Large

In the Properties of the coded UI test, create a new Data Connection String. The connection string wizard lets you choose your source of data. Within the code, you can then write statements such as

C#
var flavor = TestContext.DataRow[“Flavor”].ToString();

Isolate

As with any unit tests, you can isolate the component or layer that you are testing—in this case, the user interface—by providing a fake business layer. This layer should simply log the calls and be able to change states so that your assertions can verify that the user interface passed the correct calls and displayed the state correctly.

Test first?

You might think this isn’t one of those cases where you can realistically write the tests before you write the code. After all, you have to create the user interface before you can record actions in the Coded UI Test Builder.

This is true to a certain extent, especially if the user interface responds quite dynamically to the state of the business logic. But nevertheless, you’ll often find that you can record some actions on buttons that don’t do much during your recording, and then write some assertions that will only work when the business logic is coupled up.

Coded UI tests: are they unit or system tests?

Coded UI tests are a very effective way of quickly writing a test. Strictly speaking, they are intended for two purposes: testing the UI by itself in isolation (with the business logic faked); and system testing your whole application.

But coded UI tests are such a fast way of creating tests that it’s tempting to stretch their scope a bit. For example, suppose you’re writing a little desktop application—maybe it accesses a database or the web. The business logic is driven directly from the user interface. Clearly, a quick way of creating tests for the business logic is to record coded UI tests for all the main features, while faking out external sources of variation such as the web or the database. And you might decide that your time is better spent doing that than writing the code for the business logic.

Cover your ears for a moment against the screams of the methodology consultants. What’s agonizing them is that if you were to test the business logic by clicking the buttons of the UI, you would be coupling the UI to the business logic and undoing all the good software engineering that kept them separate. If you were to change your UI, they argue, you would lose the unit tests of your business logic.

Furthermore, since coded UI tests can only realistically be created after the application is running, following this approach wouldn’t allow you to follow the test-first strategy, which is very good for focusing your ideas and discussions about what the code should do.

For these reasons, we don’t really recommend using coded UI tests as a substitute for proper unit tests of the business logic. We recommend thinking of the business logic as being driven by an API (that you could drive from another code component), and the UI as just one way of calling the operations of the API. And to write an API, it’s a good idea to start by writing samples of calling sequences, which become some of your test methods.

But it’s your call; if you’re confident that your app is short-lived, small, and insignificant, then coded UI tests can be a great way to write some quick tests.