Automation testing UI. From Coded UI to Cruciatus

As you know , 2GIS helps to find a variety of relevant information about the organizations of the city. It is collected from various sources with the help of specialized products with which 2GIS cartographers, call-center and sales department specialists work. We call these products internal, and in addition to collecting information, they also know how to process it, filter, merge and upload in the right formats to the final 2GIS applications.

Internal products are developing individual project teams, mainly on the Microsoft technology stack. To draw a graphical interface, use WPF or hereditary WinForms. Some applications are built on controls from the "box", others use, for example, the AvalonDock library. Also there are applications developed on the Catel platform.

This diversity creates problems with test automation. We successfully solved them within the framework of the Cruciatus project - our own framework, which allows us to simplify the development of tests for testing the user interface.
')
Despite the name, Cruciatus is completely legal and you will not be sent to Azkaban for its use. In this article we will talk about ruciatus more.

Choosing a magic wand tool

The main task of automating functional testing is to reproduce the steps of the test case. That is, the autotest should repeat the same actions and checks that the tester does during manual testing. These tasks are solved with the help of specialized tools that allow you to emulate custom actions.

For desktop applications for Windows, we looked at several of the most popular tools: Visual Studio CodedUI, Ranorex, White and selected the most suitable for testing our internal products. Earlier on Habré we wrote what principles guided us when choosing.

Recall that we have made our choice in favor of CodedUI. He did not win on all counts, but had a weighty advantage in that work with him takes place directly in Visual Studio, which is the main development environment for developers and testers.

Why do we need a boomerang if we have a rake

Recorder is a distinctive feature of CodedUI, as it allows you to create tests even without programming skills.

In our experience, the CodedUI test script is easily reproduced for calculator applications. However, if the interface contains a lot of non-standard or dynamic controls, errors arise when defining them. In addition, it is problematic to make changes to the test code, since the code generated by the recorder is very massive and confusing.

Since by that time we already had an idea about the work of CodedUI, we put the recorder aside and began to write test code on our own, using the classes provided by the Microsoft.VisualStudio.TestTools.UITesting namespace (CodedUI uses them when generating code). This allowed us to get tests with clear, compact code, but did not get rid of the problems of finding items and their availability. What blocked the further advancement of user interface testing automation.

Imagine CodedUI in work as an infrastructure consisting of classes of the framework, the application under test and the tests themselves. Details of the components are shown in the diagram:



We were completely satisfied with the work of the components that emulate mouse and keyboard actions: the Mouse & Keyboard classes do an excellent job with this. Unlike classes that are responsible for access to the application and are extreme for the mentioned problem of search and accessibility of elements. In this regard, I want to cut and replace them!

Its wrap closer to the body

In order for an element of an application to say something about itself, it must implement the Microsoft UI Automation technology. In this case, it allows you to programmatically access it using the libraries from the System.Windows.Automation namespace. They are used, for example, in the WpfTestProvider class already mentioned in the diagram. We tried to directly use the Automation library and got an excellent result, getting rid of the problems of finding an item and their availability.

However, the provided functionality of the Automation library does not allow performing ordinary actions (find an element, click on it, get its text, etc.) in one method. Therefore, using the Automation library to the tester in the forehead would be wrong.

So, the next stage in the development of our project was the development of a wrapper over UI Automation, which will replace the classes that do not satisfy us,



accumulates satisfying,



and for the tester will be a versatile and easy-to-use tool.

Magical transfiguration

The wrapper has "grown" and now it is a tool for developing functional tests with the code name Cruciatus. We give an example of the development of a test project with its use.

To work you need to build a map of interface elements. It should indicate the type and unique identifier of each element participating in the testing. It is important that the type is chosen from those available in Cruciatus. Using the card makes it easy to maintain tests with changes in the interface, and you can draw it in the form of a tree:



Using the map, we write tests. Below is an example of a test that checks that when the checkbox is checked (for the SwitchCheckBox element), the ComboBox element is enabled and vice versa:

[CodedUITest] public class Class1 { [TestMethod] public void CheckingSwitchCheckBox() { var app = new Application<MainWindow>("Application.exe", "WindowUid"); app.Start(); app.MainWindow.TabItem2.SwitchCheckBox.Uncheck(); //  ComboBox Assert.IsFalse(app.MainWindow.TabItem2.ComboBox.IsEnabled); app.MainWindow.TabItem2.SwitchCheckBox.Check(); //  ComboBox Assert.IsTrue(app.MainWindow.TabItem2.ComboBox.IsEnabled); app.Close(); } } 

Automate and revest

The framework is available on GitHub , the documentation is attached. The product is completely ready to use. Cruciatus was originally developed for personal use, but now it has grown into an independent product that we are actively developing.

Download, fork, rekvestiruyte features. We welcome your wishes and suggestions.