Is Coded UI Test under Load Test supported?

  • Article

I have seen multiple queries on “Is running Coded UI Test under Load Test supported?”.

Well, the short answer is – yes, it is supported with restriction of one user-load per test agent and in most cases it does not make sense in using Coded UI Test under Load Test.

If that left you baffled, read on the long answer.  Running Coded UI Test under Load Test does not make sense (leave aside the restriction of one user-load per test agent for time being) because -

  • You want to load your server with large number of user requests.  Using Coded UI Test for these request would mean only 1 request per process at a time. In other words, you need as many processes as the number of simultaneous request load that you want to put on the server.
  • Doing actions on the UI will take more time then directly calling the function\server request. For example, a form fill (type values in bunch of fields & submit) scenario might take couple of seconds on the UI because it has to find controls and type on those to generate one server request.

Put both the above together and it means to put a reasonably good load on the server, say 100 simultaneous user, you will need good deal of test client resources.

The restriction of one user-load per test agent is there because typically a series of UI operations form one atomic unit.  For example, click one Open menu is actually two step – click on File menu and then click on Open menu.  Similarly setting selected item property of combo box means opening the combo box drop-down, scrolling to the right item and clicking on it.  In both these cases, if the focus shifts to another window or other click operation happens, the menu or drop-down will collapse resulting the test failure.  The option to workaround this would be either take some lock to synchronize which will further create scaling problem (and also perf problem in normal case) or not do the actions via UI but fake it via script calls or windows messages in which case it is not really a UI test.

Given the above scale issues, we thought the priority of solving running multiple Coded UI Test simultaneously (in parallel) in one user session is much lower priority.

The easy and correct alternative is to use Web Performance Test (for web applications) or Unit Test (for other application by making the equivalent server calls from code) in the Load Test. These are much more scalable and better suited for this scenario.

The case where you might still use Coded UI Test under Load Test is to get UI timings against a server under load. Load the server using Web Performance Test or Unit Test and have a single Coded UI Test in the mix to get the client UI performance information.