Sencha application UI Testing

Original article: http://www.sencha.com/blog/ui-testing-a-sencha-app/

A few months ago, I wrote an article entitled "Automated unit testing", covering how developers compile unit testing and verify Javascript syntax for business logic. You must understand these concepts when creating an enterprise application: You must capture errors or potentially catastrophic consequences before an update is pushed to a product.
One area not covered in that article is the concept of "UI Testing, also called Integration Testing, Integration Testing. After reading a lot of comments about that article and hearing community feedback, I decided to post an article about adding UI testing in ExtJS applications and discussing enterprise application testing strategies.
UI testing: As mentioned above, the two concepts of UI testing and unit testing are often confusing.
UI TestingWhat we need to do is to subjectively verify that the element behavior on the screen includes the appearance) whether it is as expected, which includes static plane rendering) and the behavior given by dynamic user operations.Unit TestIt is for small pieces of code and objectively verifies the application logic.
Their main difference lies in the subjective and objective nature of the test.
This concept further divides the UI test into two components:QA testingAndComponent Test.

• QA testing simulates the interaction between the real world and applications when users use applications.
• Component testing is to divide the application into different blocks that can be reused) to verify their display and behavior.

In this article, we will see these two types of UI tests.
Choosing the right tool to test the appearance of an application and complex interactions is a daunting task. Therefore, many Web developers usually give up to resist) it is no surprise to solve the QA problem through UI testing.
In fact, the biggest obstacle that developers need to solve is to choose the best tool for this job. Some tools rely on Xpath or CSS selectors to browse applications. In addition, complex server configurations are required for automated testing. In the final analysis, it is very important to choose flexible tools. QA testing will be frequently rewritten due to changes in business requirements or application modifications. Therefore, testing is easy to create and maintain.
Based on my experience, there are three tools suitable for QA testing of Sencha applications:

• Selenium
• CasperJS needs to run on the PhantomJS platform)
• Siesta

Each of these tools has outstanding advantages and disadvantages. However, I personally think Siesta is easier to configure, and its API can work seamlessly with the Sencha framework.
Disclaimer: I do not advocate using other UI testing tools. I do not advocate that Siesta is the "best" tool currently. I only provide comments based on my own experience.
Analog data
Another important issue of using UI testing is that testing is often not written for online APIs. For whatever reason, the API itself is not reliable: server downtime, network latency, and exception errors.
The purpose of the UI test is to verify the display and behavior, rather than the specific data that exists at any given time. If possible, the UI test should simulate API data, but this is not an easy-to-solve problem. Some implementations use static data of Ajax requests, while others need to redirect network calls to simulate APIs.
Not only is it difficult to control the Javascript simulation inventory, but I am not going to discuss this issue in depth in this article. I just want to let everyone know about this issue, because it is often frustrating. In the example application, Sinon. js is used as the API call stub.
After talking about this, you may feel that you should use online APIs. However, I generally recommend that you use online APIs only when verifying the release version.

Sample Application
In the example Ext JS application, you can find the QA test/app/) and component test/ux/written using Siesta in the ui-tests folder /).
650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/12105613Q-0.png "alt =" "/>
In the/app/folder, you can open the index.html file in the browser to view the Siesta interface of the QA test. The goal here is to run the actual application and test the real-world interaction that the user expects. Although the sample application is a simple example, the two QA tests demonstrate different ways to test the full behavior of an application.
The first test, named "Testtabs for data in grids"/app/tests/01_tabs.js), simply loads the application and checks whether the requested view is correctly displayed. Although this special example is primitive, the test results may be useful when an application dynamically creates its interfaces based on user roles, preferences, or other logic.
The second test, named "Testdouble-click functionality"/app/test/02_rsvp1_1_js), will reload the entire application. This time, the interaction between the Grid and the tag should be simulated to ensure that the required behavior is executed as expected.
It must be noted that the Sinon. js file is used as the stub of the Store's JsonP request. In this way, you can test the functions of an application without assuming that the online API can be accessed and work properly. There are many ways to do this. Here we chose to rewrite Ext. data. jsonP. request () to automatically return the simulated data, see/ui-tests/app/api_stub.js ).
In the/ux/folder, you can open the index.html file on the browser to view the Siesta interface of the component test. Unlike QA testing, the goal here is to separate components and test their behavior. By testing components other than large applications, you can isolate known errors and ensure future compatibility.
The only test for the sample application/apuxp/tests/01_rsvp1_1_js) is to check the display and behavior of the RsvpWindow view. By default, the view extended from the Window class) is displayed with a size of 300 × 300 and a title as the modal Window. With Siesta, an independent view instance is created and these default configuration attributes are verified. [Javascript]View plaincopy

1. Var defaultWin = Ext. create ('chicagmeetup. view. rsvpwindow ',{
2. // Default configs
3. });
5. T. is (defaultWin. modal, true, 'rsvpwindow shocould be modal .');
6. T. is (defaultWin. title, 'rsvps for the selected meetup', 'rsvpwindow shocould have a title of "RSVPs for the selected Meetup ".');
7. T. is (defaultWin. getHeight (), 300, 'rsvpwindow shocould be 300px tall .');
8. T. is (defaultWin. getWidth (), 300, 'rsvpwindow shocould be 300px wide .');
9. T. is (defaultWin. getLayout (). type, 'fit ', 'rsvpwindow shoud have "fit" layout .');

This is very useful and a good note. It can ensure that RsvpWindow can be customized for reusability. In the Siesta test, you can create another RsvpWindow instance. However, this time the default value will be overwritten to ensure the initialization process is successful. [Javascript]View plaincopy

1. Var customWin = Ext. create ('chicagmeetup. view. rsvpwindow ',{
2. Modal: false,
3. Title: 'foobar Window ',
4. Height: 400,
5. Width: 200,
6. Layout: 'card'
7. });
9. T. is (customWin. modal, false, 'rsvpwindow shocould be modal .');
10. T. is (customWin. title, 'foobarwindow', 'rsvpwindow shoshould have a title of "Foobar Window ".');
11. T. is (customWin. getHeight (), 400, 'rsvpwindow shocould be 300px tall .');
12. T. is (customWin. getWidth (), 200, 'rsvpwindow shocould be 300px wide .');
13. T. is (customWin. getLayout (). type, 'card', 'rsvpwindow shoud have "card" layout .');

The powerful Siesta test API can be used to simulate various interaction methods of components, such as click and drag ). Although the RsvpWindow component is not exciting enough, you can imagine the possibility of custom UX classes.
Conclusion creating a unit test for a Web cherry blossom program may be an arduous task, but the reward for the effort is priceless. Finally, I would like to reiterate the following points:

• Unit testing and ui testing are different.Both of them are valuable for maintaining stable code, but they are used to solve different problems.
• Pay attention to the syntax.Because the code can run correctly in a browser does not mean that it can run correctly in every browser.
• Test custom components. The framework runs normally as expected. However, do not think that UX is correct.
• Do not target code coverage of 100%.There may be an idea to test the entire application, but consider the cost of maintaining a complex test suite.

This series of articles on unit testing is based on the author's personal experience to help Sencha users solve common problems. I will learn more in the webinar. The author will host Mats Bryntse in January 31 to introduce developers to practical methods for testing Ext JS and Touch applications. The registration address is here. In addition, we invite you to share your thoughts and experiences and hope that you can help each other to make Web application testing easier to achieve your goals.

Author: Arthur Kay
Arthur Kay has been working with the Web since the late 1990 s, when GeoCities and scrolling marquees were all the rage. since those early days, Arthur graduated from Loyola University Chicago (where he studied Music and Computer Science) and has worked in a variety of professional roles throughout the Internet industry. arthur currently lives in the Chicago suburbs and works as a Solutions Engineer for Sencha, Inc.