CODEWITHSUNDEEP
c#multithreadingtestingarchitecturecoded-ui-tests
Conrado Costa
Conrado Costa

Reputation: 435

Coded UI Test issues with threads / performing repeated actions periodically

I'm automating tests in a system built in VB, so I can't get a lot of controls in this system with the "Coded UI Test Builder" tool. Said that, I built a method to took a screenshot and compare a region to verify if the system threw an error window (not really a window, I can't get this one with the tool either) and this function was called periodically in another thread, but I received that the exception: 

Microsoft.VisualStudio.TestTools.UITest.Extension.UITestException: The Coded UI Test is running in Single Thread Apartment (STA) mode of COM. In this mode, all the playback calls should happen from the TestMethod thread only and UITestControl should not be shared across TestMethods.

Then I figured out that UI Test do not support multi-thread, and I was forced to call the function to verify the error after each interaction with the system (e.g. generate a report, verify error, close the report, verify error).

Probably the a better way to do that or a software design pattern, but I'm just beginning with automated tests and don't know what should I do to improve that test.

My questions is: is that a better way? What is it.

Upvotes: 0

Views: 732

Answers (1)

Alex P
Alex P

Reputation: 275

That's right. Coded UI does not support multi-threading and as it is written in the exception, the UITestControl cannot be shared in multiple test methods.

However, you can start another thread, where you make a screenshot without using Coded UI and its Playback. If you are looking for a particular message box, you can combine Coded UI functions with WinApi functions. You can call WinApi functions from another thread running in parallel to your Coded UI.

I would recommend to avoid multi-threading and to stick with Coded UI sequential approach. That is when you do an action (mouse click, input from keyboard etc.) and then make a verification whether the interaction with UI works as expected.

If your error message comes sporadically and blocks other controls, you may consider using Playback.Cleanup() (about Cleanup() on MSDN). This method will be called automatically when test playback will be disrupted or finished. If your error message is represented by modal dialog, then I assume that other controls will be blocked. When the Playback cannot perform the required action on a control, it stops and the Cleanup() method will be called, where you can explicitly check whether your expected error caused the playback to stop.

But I would still recommend to use a sequential approach and check the results of your UI interactions with the Coded UI methods (Asserts and etc.)

Hope one of these helps. If not, then please provide the additional information about the error message you are struggling to handle.

Upvotes: 1

Related Questions