Team Development Series – Part 4: Testing the LightSwitch Application (Saar Shen)

Team Development Series – Part 4: Testing the LightSwitch Application (Saar Shen)

Rate This
  • Comments 3

Using Visual Studio 2013, we can create automated test projects like a Coded UI Test or aWeb Performance and Load Test to test LightSwitch Applications. A Coded UI Test is used for creating automated tests for the UI. A Web Performance and Load Test is used for creating performance and load tests for the server. In this article, I will walk through the steps of how to create both types of automated tests for LightSwitch applications.

Let’s begin with a LightSwitch project that you want to test. For this example, I’ll use an Order Management System based on the Order table of the Northwind database. The Order Management System performs the basic tasks of creating, retrieving, updating and deleting orders and contains three screens:

Browse Orders – This is the home screen. It shows a list of orders and several buttons to add, edit and view the order details.

View Order – This shows the details of an order in read-only mode and provides a button to delete the current order.

Add Edit Order – This is a screen shared by adding a new order and editing an existing one.

With our application in place, we can now write our automated tests. We will look first at writing a Coded UI Test and follow with writing a Web Performance and Load Test.

Coded UI Test

First, we need to design a scenario for the test. For this example, let’s test changing an Order’s Ship Name field:

Get an order, edit its Ship Name, save and check the result.

Next, we need to break down the scenario into steps:

  1. Locate an order in the Browse Orders screen.
  2. View its details in the View Order screen.
    • Record the Ship Name field from the View Order screen.
  3. Open the Edit Order screen.
  4. Verify the Ship Name field in the Edit Order screen is the same as that recorded in step 2.
  5. Change the Ship Name field in the Edit Order screen and save it.
  6. Verify the value has been changed to new value on View Order screen.

With the steps above, let’s implement the Coded UI test project. Right click on the solution node in the Solution Explorer, then click Add -> New Project. Select Coded UI Test project template under Visual C# / Visual Basic –> Test and give it a name, for this example, I’ll call the test project OrderManageSystem.CodedUITest.

image

You will be prompted to choose how you want to create the Coded UI test. Choose Record actions, edit UI map or add assertions since we don’t have any existing action yet. Click OK and you will see a Coded UI Test Builder on the right-hand corner of the screen like this:

image

If you missed the dialog, don’t worry, you will see an empty test method in the code editor and you can always reach the same point by using the context menu in the method body:

image

Let’s launch our LightSwitch application in the browser by using Start Without Debugging on the DEBUG menu (Ctrl+F5).

image 

Once the Browse Orders screen pops up, click the red Record button on the Coded UI Test Builder to start recording.

image

In the browser, click on an order such as 10249 and then click on View Order button.

image

Click on the Show Recorded Steps button at the right of Record button to review the process:

image

From top to bottom, we can see all the recorded steps. It is recommended to delete any unnecessary steps that are not needed for the actual test. This will reduce the noise and the test will run faster. For example, I will remove the steps with Mouse hover… because we don’t need to verify that the mouse is hovering over a specific object when the test runs, we just want to test the controls themselves. Improving the performance of your Coded UI tests describes ways to customize the settings for recording hover behaviors. Once we’ve cleaned the test up, things are much clearer.

image

Now that we’ve finished recording the test actions, click Generate Code on the Coded UI Test Builder. Name the method for the first step ViewTargetRecord and put in a meaningful method description. This will really help when you need to visit the code later.

image

Click Add and Generate button to generate the code.

Next, record and generate another method for the second step. Click the Record button on Coded UI Test Builder again. In the browser, click on the Edit button to bring up the Add / Edit Order screen and generate a method named PopUpEditTargetRecord.

image

Now I want to check the Ship Name for the record is Toms Spezialitäten. Instead of clicking the red Record button, click the third button on the Coded UI Builder, which is Add Assert Button, and then drag & drop it onto a control that you want to verify. Let’s take the Text Box for Ship Name for example.

image

An Add Assertions dialog will come up. You might need to use the four-direction arrows to locate the target control because there might be layers of controls at the same spot.

image

When you find the exact control that needs to be verified, click on the property that you are interested in, such as ValueAttribute, and click the Add Assertion button. This will bring up another dialog where you can choose a comparator and modify the expected value if needed. You will also be asked to supply a message that will be displayed when the assertion fails.

image

Close all the pop ups and focus back to the Coded UI Test Builder, then click the Generate Code button to generate an assert method. The third step is now done.

After the code is generated, we can use the same technique to start recording again by clicking the Record button. This time, enter a different name in browser (Dummy ship for example) for the Ship Name field and then click the Save button. Clear up the recorded steps and then generate code. To finish the last step, we use the Add Assertion button again to verify the new Ship Name has been changed to Dummy ship on View Order screen.

After all the steps are accomplished, we can click the close button on the Coded UI Test Builder to finish the recording.

Let’s take a glance at the code that was generated.

image

We have five methods for the steps of the scenario. Hover over the method and you will see the method description that we entered previously.

We need to run the test case to make sure that it works when the recorded methods are put together. First, refresh the browser to reset to the initial values. Then right click on the test method in the Visual Studio code editor and click ‘Run Tests’.

image

Sometimes, you might have to wait between the method executions. For example, your LightSwitch application may need to wait for a while after an item is clicked in the list. There are several events that you can specify for the tests to wait on like wait for the control to be ready or wait for the control to be enabled and so on. Please refer Making Coded UI Tests Wait For Specific Events During Playback for all specific events a CodedUI test can wait on. In this example, we will add wait for the control to be ready after clicking the Order record from the Browse Order screen in the first step. Locate the method this.UIMap.ViewTargetRecord() for C# and Me.UIMap.ViewTargetRecord() for VB. Click Go To Definition in the context menu to see the details.

image

Add the line in bold to the code as shown below:

 


 

C#

 // Click '10249' custom control Mouse.Click(uIItem10249Custom, new Point(114, 31));
uIItem10249Custom.WaitForControlReady();

 


VB.NET

'Click '10249' pane Mouse.Click(uIItem10249Pane, New Point(114, 31))  uIItem10249Pane.WaitForControlReady()

 


When the time issues are addressed, run the test case again. There’s an assertion fails:

image

The message says that it is expecting Toms Spezialitäten but the actual is Dummy ship. Well, that’s true because although we reset the website by refreshing in the browser, we didn’t change the value back before we ran the test again.

To quickly fix the issue, change the value back to Toms Spezialitäten.In practice, you should reset the database to a known state every time you run your tests.

Now when you run the test again, the test case passes.

image 

Hooray! Now let’s move on to performance testing.

Web Performance and Load Test

Coded UI tests help us test the quality of the UI, while Web Performance and Load tests help us test the quality and stability of the service provided by the LightSwitch middle-tier. I’ll keep using the Order Management System here as the test target. Open the project and add another new project into the solution like before, but choose the Web Performance and Load Test as the project template (which sits beside the Coded UI Test project template). Let’s name the project OrderManagementSystem.PerfTest.

image

We need to have a scenario to test our LightSwitch application. To make the example simple, I picked a very basic scenario:

Add a new record. And I split it into these steps:

  1. Start the application by URL
  2. Click Add Order on Browse Orders screen
  3. Input content in the required fields in Add Edit Order screen
  4. Save the changes

Click the Record button on top of the WebTest1 that is created by the project template.

image 

This brings up the browser with a record panel on the left:

image

Type in the URL of the LightSwitch application, http://localhost:53098/HTMLClient for example, to start with. When the screen loads, recorded requests show up on the Web Test Recorder panel like this:

image

In the browser, click Add Order to pop up the Add Edit Order dialog. Input some data and save the changes.

image

Click on Stop button to stop the record.

image

At this point Visual Studio takes it over and generates the test.

Let’s run the test by clicking on the Run Test button on left upper corer of the test case.

image 

You will see we have a few errors for the first request. When you expand the node, you see missing client.lang-EN-US.resjson and service.lang-EN-US.resjson files. Those files are used by LightSwitch localization. Refer Localizing a LightSwitch Application for details. Since we don’t provide any resource strings for EN-US, we don’t expect the files to exist here. Let’s remove the verification since it is unnecessary for our app. Right click on the test result and click Go to Web Test.

image

Right click on the verification steps and delete the steps for those resjson files.

image

Save the test case and run it again. Now everything passes.

image

Notice here that we can see the Request, the Status, the Total Time, the Request time, the Request Bytes and the Response Bytes. This allows you to identify scalability and performance issues.

This is just the tip of the iceberg when it comes to Web Performance and Load Test projects. Based on the test project we have, you can build series of other tests. For example, you can build a Load test, run it and get a report like below. Please read Web Performance Test Walkthroughs, Testing Performance and Stress Using Visual Studio Web Performance and Load Tests and Customizing Web Performance Test Recordings Using Web Performance Test Editor for more information on how perform effective performance and load tests.

image

 

Have fun! And please visit our forums for troubleshooting and feedback on Visual Studio LightSwitch. We look forward to hearing from you!

- Saar Shen, Tester, LightSwitch Team

Leave a Comment
  • Please add 1 and 6 and type the answer here:
  • Post
  • Thanks for this article.

    I tried running CUITs before in LS V1, but had some difficulties with the SilverLight client.

    the test recorder had difficulties recording the autocompletebox and the datetime picker controls.

    Has this been solved in VS2013, or do you only support CUITs with the HTML Client?

  • @Michiel - CUIT is especially awesome now, VS 2012 with Update 1 or later, with regards to web HTML automation (it supports multiple browser types, and is in general a lot more functional and reliable.)

    With regards to automating Silverlight Clients, it can be, from my experience, a bit hit miss.  There are some work arounds you can do for things like the Date Time Picker - for example if you "paste" in the date time value, or if you use keyboard shortcuts instead of mouse clicks, you usually have better luck.

  • Thanks for your response Matt. I'll try it out

Page 1 of 1 (3 items)