Automated testing of Eclipse GUI based on Swtbot

Background introduction

In the field of software development, continuous integration and deployment are increasingly demanding for software test automation, and Eclipse-based applications still occupy an important part of this requirement. At present, the main test automation tools mainly with the function of recording playback, assisted by script. However, the test method based on this often has the complexity of test case maintenance, the test process is easy to fail, which directly affect the test efficiency.
Swtbot, as the automated testing tool recommended by the Eclipse website, offers a professional class library and extensibility points that are inherently advantageous in automated testing of eclipse applications.

Swtbot is an open source UI and functional testing tool based on Eclipse SWT, with easy-to-use API support and natural compatibility for applications built on the eclipse rich client Platform to help users quickly and efficiently Build automated test frameworks for specific applications.

At present, most of the Eclipse Automation testing tools mainly use the recording-playback mode to create test cases, while the script to maintain business logic, often a test to involve the maintenance of multiple scripts, which greatly improve the requirements for testers, and recording-playback is due to its mechanism of instability, Often makes testing impossible to get accurate results in a specific time period.

Since its inception, Swtbot has been greatly improved and popularized in the Eclipse community, making it increasingly stable and mature. This paper presents a test framework based on XML describing test cases and supporting user UI operating language, which is intended to:

1. Reduce technical requirements for developers to focus on operational processes and business logic
2. Provides a scalable test case description format that provides the ability to reuse test cases
3. Build the basic terminology of Eclipse UI operations and increase the ability of the framework to expand
4. Automate output test results to increase testers ' productivity

System structure

Based on Swtbot's open source framework, this article expands its support, encapsulation, and implementation of the Eclipse basic controls, improves its efficiency, and enables an automated testing framework that adapts to new scenarios at lower maintenance costs. At the same time, this paper proposes that the test case is described based on XML and provides a unified test description language and parsing method.

The architecture of the Automated Test Framework (hereinafter referred to as "the framework") is as follows:

Figure 1. Swtbot-based Eclipse UI Automation test Framework Architecture

As the only input to the framework, we use XML as a unified language for describing test cases. In the following sections, we describe the XML meta-languages and operations that we abstract and define from a particular application, a complex test step consisting of several meta-languages and operations, a set of test steps that comprise the test case, and a set of test cases that comprise the test Suit.

At the bottom of the framework, the Swtbot class library is included, in which the method of recognizing and retrieving the basic control of Eclipse is implemented. Bottom, in the third-to-last layer of the framework, we extend support for specific controls based on the Swtbot base Class library, such as controls for pagination composition, ensuring that specific controls in a particular application can be easily found in test execution. The advantage of this is that different products can reuse the implemented controls while extending the controls that are needed. At the same time, to improve the efficiency of control retrieval and to support the implementation of test logic, we implemented the Utilities toolset to maintain standard input output in test cases, as well as source data for generating test results, and to accelerate execution efficiency.

At the top level of the framework is support for test cases in the standard input XML format. Through the definition of a property file, the framework is able to quickly parse all test sets in a particular directory, establish sequential execution, execute sequentially, record the execution status of each test step, and, depending on the definition in the properties file, determine whether an error is exited or continues execution.

Test Case XML-based test case description

Now, we stand in the perspective of a tester to demonstrate how easy it is for testers to work with this extended Swtbot test framework. Furthermore, the use of XML as a description tool for test cases makes it easier for testers to write test cases, greatly reducing the need for testers to encode, and allowing testers to focus on the only thing that can be done to compose XML test cases.

Create a test project

In the first step, the tester needs to create an empty project. For example, here the tester creates a test project called "Com.ibm.team.enterprise.swtbot.sample". The tester then creates a folder Sampletestsuit to place the test description file. This folder contains a Properties folder, which is used to store property files. The tester can then add several test cases as needed, where we have added 2 test cases: Sampletestcase1.xml and Sampletestcase2.xml. In this way, the test project is created, and its structure:

Figure 2: Test Engineering structure diagram based on XML description

Next, all the tester's job is to focus on writing XML test cases. And, with the XML editor that comes with Eclipse, testers don't even have to care about the syntax of XML, they just need to add the Command to the template and provide the corresponding value in step-by-step.

Figure 3: Using an XML file to describe a GUI test case

As an example, suppose the tester wants to add a Click button action after the last Command in Firstteststep. Then he just needs to right-click Select "Add after" and select the Command option. And then add the attribute to the command command in the same way, which is really very simple and greatly facilitates the work of the tester.

Properties configuration file

In a test project, the Properties configuration file defines a series of key/value pairs. The Propertires file has two functions. The first function is to define variables so that they can be referenced in the XML test case. The method of referencing a variable is also simple and can be referenced by the format of the ${variable name}. For example, in the example above, ${button_summit} refers to the variable button_summit defined in the Sampletestsuite.properties file, which is useful for improving the portability and extensibility of XML test cases. The second role of the properties profile is to be external, and all widget text on the UI is given a pair of unique keys/values, so that, in the context of UI globalization, different widget texts set different values according to different locales, when the properties These external variables defined in the file are particularly important.

Figure 4: The Properties Property file framework implementation of the Test project

Swtbot, as the official UI Automation test tool recommended by Eclipse, is itself based on Hamcrest and JUnit to execute test cases (TestCase) and test sets (Testsuit) written in the Java language. However, this requires testers to be proficient in the Java language and be proficient in JUnit. Since we changed the Swtbot execution target file and made it our custom XML form test case file, we implemented an XML language-based Eclipse UI Automation testing Framework. In this way, testers can get rid of the heavy work of code and focus on the business logic of the actual test object. The implementation of Swtbot's most core test UI, combined with the expansion and enrichment of its core components Finder, Matcher, Widgets, Condition, and Assert, constitutes the main content of the framework's implementation.

The principle of primary Swtbot's execution

Before detailing how the framework is implemented, you first need to have an in-depth understanding of Eclipse's own architecture, what is a plug-in (plug-in), what is an extension point (Extension Points), what is an extension (Extensions), what is dependency ( Dependencies), what is OSGI (open Service Gateway Protocol) and so on. You then need to understand the fundamentals and basic operations of the main components of the Eclipse rich Client (RCP) work platform (Workbench), views, editors (editor), and Perspective (perspective). These basics can be learned in resources, and this is no longer a statement. Let's take a look at the basic principles and execution sequence of Swtbot. We use Swtbot to simulate the actions of the user for each part of the Eclipse RCP application and to join the verification point to verify the results of the operation execution. Swtbot itself is an application of Eclipse (application), but it implements a test interface itestharness of Eclipse itself. When the tested application starts, Eclipse launches the Swtbot application to load the test cases and test sets of JUnit customized by the command line, and then, through the Swtbot Swtworkbenchbot factory class, to find the working platform in the tested program, And on the work platform to pick up the test parts to initialize the corresponding Swtbot part instance, by the Swtbot part instance to the corresponding operation, and finally return the operation results to Swtbot for verification. At first glance, the entire implementation process is relatively simple, and it seems to be used. But invoking the static method provided by the Swtbotfactory factory class to get the corresponding Swtbot object for the test control and to manipulate the object requires an in-depth understanding of the basic composition and operational nature of the rich client program. Our framework simplifies the retrieval and manipulation of controls by simply specifying simple XML elements and setting corresponding property values in accordance with the specifications of our defined XML metadata, which makes it easy to find elements, manipulate elements, and set test points for validation.

Extensions based on Swtbot basic controls

Our framework first adds support for each chapter (section) in the Multi-layer editor (Multipleeditor) and editor in the Swtbot Finder component. This makes it easy for users to test the complex editor and chapters in a targeted way, rather than working in a basic, general-purpose editor as Swtbot originally did. Then, in the widget component of Swtbot, new support was added for parts such as the composition part (Composite), the scrolling form (scrolledform), and the form page (FormPage). Finally, especially in the Matcher components of Swtbot, the method of finding parts according to different conditions and enriching the operation mode of multi-level right-click menu, further expanding the original Swtbot can not be well supported areas, greatly enhanced the Swtbot in the Eclipse RCP Automation test can Force.

Figure 5: Extension of the Matcher component of the Swtbot Figure 6: Extension of the Widgets component of Swtbot to improve the efficiency of control retrieval

For the principle of Swtbot retrieval control, if you have studied its source in detail, it should be very clear. Swtbot for each SWT control, there is a corresponding Bot object that encapsulates the operation of the control and the properties and state of the control. At the same time Swtbot has a Swtworkbenchbot class, which is the factory class of almost all the bot objects in Swtbot, and is the basic entrance to find these bot objects. This factory class is typically created directly, and the path to the default retrieve control is from the total working platform (Workbench) of Eclipse RCP, and then from all views, menus, context menus, toolbars, Place the status bar and editor to find the control object that needs to be tested and manipulated, and then create the Bot object. Under this kind of control retrieval mode, the execution efficiency must be very low. Our automation Framework optimizes this general method of retrieving controls by adding an object called the Operation area, which allows you to pinpoint where the search begins, to the view or editor that the control is contained in, to narrow the scope of the search, to increase the accuracy of the search, and to improve Swtbot the efficiency of the operation.

Listing 1: Getting the core code for the Operation area

1Oatype Oatype =Oa.gettype ();2String ID =Modelutil.getlastoutputvalue (Oa.getid (), laststepoutput);3String title =Modelutil.getlastoutputvalue (Oa.gettext (),4 laststepoutput);5swtbotworkbenchpart<?extendsIworkbenchpartreference> Oapart =NULL;6     if(Oatype.view = =Oatype) {7Oapart =Bot.showview (ID, title);8}Else if(Oatype.editor = = Oatype | | Oatype.texteditor = =Oatype) {9         if(NULL! = ID && id.length () > 0) {TenOapart =Bot.editorbyid (ID); One         } A         if(NULL= = Oapart &&NULL!=title) { -Oapart =Bot.editorbytitle (title); -         } the         if(Oatype.texteditor = = Oatype &&NULL!=Oapart -&& Oapartinstanceofswtboteditor) { -Oapart =((swtboteditor) oapart). Totexteditor (); -         } +}Else if(Oatype.eemultople_editor = =Oatype) { -         if(NULL! = ID && id.length () > 0) { +Oapart =Bot.multipageeeeditorbyid (ID); A         } at         if(NULL= = Oapart &&NULL!=title) { -Oapart =Bot.multipageeeeditorbytitle (title); -         } -         if(NULL= = Oapart &&NULL= = Title &&NULL==ID) { -Oapart =bot.getactiveeditor (); -         } in}Else if(Oatype.perspective = =Oatype) { -Swtbotperspective perspective =NULL; to         if(NULL! = ID && id.length () > 0) { +Perspective =Bot.perspectivebyid (ID); -         } the         if(NULL= = Oapart &&NULL!=title) { *Perspective =Bot.perspectivebylabel (title); $         }Panax Notoginseng         if(NULL! = Perspective &&!perspective.isactive ()) { - perspective.activate (); the eeswtbotassert.assertperspectiveactivate (Perspective); +             if(NULL! = Title && title.length () > 0) { A Assert.assertequals ( the"The founded Operation area was not exepcted.",  + title, Perspective.getlabel ()); -             } $         } $     } -  

Conclusion

For those who have done automated testing, I believe everyone has experience, compared with other areas such as WEB testing, the local GUI automation testing has been a relatively difficult part, has not been a stable and efficient and lightweight GUI testing tools. On the other hand, compared to the young Web domain, the local GUI has always been a large part of the software development market, especially the rich clients such as Eclipse has been a necessary tool for enterprise software practitioners to develop. Therefore, the development of the local GUI automated testing tools for human cost and time savings is also huge.

Swtbot is an open source, Eclipse SWT-based UI and functional testing tool, and through this article, I believe you have a certain understanding of our Swtbot-based GUI automation testing framework. Because you only need to focus on writing XML test cases, it can be helpful for a large number of testers to develop high-quality reusable test cases. The first article in this series is over, and the next article will cover the process details and scenarios for GUI automation based on Swtbot extensions in more detail.

Reference Learning

• See the Eclipse Swtbot Open Source community: Download the latest version of Swtbot and get the latest news
• Refer to Eclipse SWT official homepage: Download SWT, follow the dynamics of the Open source GUI framework
• Refer to Eclipse RCP Wiki page: Follow RCP to learn about the core technologies of the Eclipse platform
• Refer to the official homepage of OSGi: Dynamic model System for Java, service-oriented architecture
• DeveloperWorks Java Technology Zone: Here are hundreds of articles on various aspects of Java programming.

Automated testing of Eclipse GUI based on Swtbot