Earlier this year Microsoft announced the end of life for Coded UI.  Visual Studio 2019 will be the last version that includes this feature.  That can present a challenge to Microsoft shops that are still building and testing thick client applications.  The good news is that there is a way forward.  With the open source boom over the last decade (or more) we have seen a proliferation of tooling in this space.  A good share of this tooling has long since been abandon, but they helped inspire some very good options. This new generation of tooling has a clear standout and that is Appium.

Appium

The Appium project was started back in 2011. The idea was pretty simple; create something like Selenium but for mobile.  The project heavily borrowed from Selenium and in fact directly users the Selenium interface.  The result was a UI testing framework that looks and feels a lot like Selenium with a couple of mobile specific add-ons.
In 2016 Microsoft released something called WinAppDriver otherwise known as WindowsDriver. It worked with standard Appium, but it had some obvious shortcoming and lacked polish. One example was that the WinAppDriver originally claimed to be an iOS Appium driver. A year or two later, after addressing some of the bugs and shortcomings, the WindowsDriver became an official Appium capability, just like iOS and Android drivers.
This really spelled the end for Coded UI.  Microsoft had been encouraging those using Coded UI for web testing to move over to Selenium for years.  Not long after WindowsDriver was officially added to Appium, it became apparent that Coded UI was no longer getting the support that it used to. And then it has become official. Microsoft officially announced 2019 would be the last version of Visual Studio to include Coded UI and they started steering folks toward WinAppDriver.

The Good:

  • First class Appium capability
  • Good for any team that knows Selenium and/or Appium
  • Works with almost any application you can run on Windows, including VB6 and Java apps
  • Supports remote execution
  • GitHub project is well mantained and has great sample code
  • Works with my preferred testing framework, MAQS
  • Tacitly supported and pushed by Microsoft

The Bad:

  • Windows 10 in developer mode only
  • Initial setup can be a little tricky
  • Does not get updated very often
  • The mobile driver itself is not open source

Alternatives

Winium

The Winium project started in mid-2015 and for a time in late 2015 it looked like it may really take off. It’s quite similar to the Appium WinAppDriver in many ways.  It leverages the Selenium interface, but Winium takes it a step further and actually created a Selenium driver. This means that Winium is basically just another Selenium web driver.

The Good:

  • Works on multiple versions of Windows
  • Supports remote execution
  • Works with most modern languages
  • Full source is up on GitHub
  • Pretty standard Selenium

The Bad:

  • Project is essentially dead; it has been about 3 year since the project received any new commits
  • Missing mobile specific capabilities found in Appium
  • Tied to an older version of Selenium, so you cannot easily create a hybrid thick client and web client testing framework
  • By default, the driver has global and not app specific scope
  • Has some hard-coded defaults that hurt configurability

Pay Tools

There are a large number of pay tools available in this space.  This includes Ranorex, TestComplete, Telerik Test Studio, plus many many more.  Frankly all these tools tend to do a pretty good job, but they all have the same issue. When something breaks you need to wait on the vendor to release a fix. For this one reason I tend to shy away from any of them. That all being said, if your test engineers have little to no development skills a pay tool is likely the best option for your organization.

Takeaway – TL; DR Version

Coded UI is going away
The best alternative is Appium, but Winium is good too
If your test engineers can't code, look at one of the other pay tools instead