The easiest way to create modern business applications for the Cloud and Office 365
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.
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.
Get an order, edit its Ship Name, save and check the result.
Next, we need to break down the scenario into steps:
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.
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:
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:
Let’s launch our LightSwitch application in the browser by using Start Without Debugging on the DEBUG menu (Ctrl+F5).
Once the Browse Orders screen pops up, click the red Record button on the Coded UI Test Builder to start recording.
In the browser, click on an order such as 10249 and then click on View Order button.
Click on the Show Recorded Steps button at the right of Record button to review the process:
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.
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.
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.
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.
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.
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.
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.
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’.
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.
Add the line in bold to the code as shown below:
// Click '10249' custom control Mouse.Click(uIItem10249Custom, new Point(114, 31)); uIItem10249Custom.WaitForControlReady();
'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:
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.
Hooray! Now let’s move on to performance testing.
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.
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:
Click the Record button on top of the WebTest1 that is created by the project template.
This brings up the browser with a record panel on the left:
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:
In the browser, click Add Order to pop up the Add Edit Order dialog. Input some data and save the changes.
Click on Stop button to stop the record.
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.
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.
Right click on the verification steps and delete the steps for those resjson files.
Save the test case and run it again. Now everything passes.
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.
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
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