We launched Sencha Test 2.0 the end of last month, and we followed it up with a webinar discussing the important updates to the product. We demonstrated how Sencha Test is the best choice for creating a robust test automation strategy using industry standard practices such as page object patterns.
While we answered many questions during the interactive Q&A session, we couldn’t get to all of them. In this article, we’ll address some of the other questions.
Watch the recording: What’s New in Sencha Test 2.0 webinar.
Is Sencha Test compatible with running apps from IE browser?
Sencha Test works with all major browsers. Within the IE family of browsers, Sencha Test works with IE 11 and above including Microsoft Edge.
Is it possible to automate testing for mobile browsers?
Tests created with Sencha Test can be executed both on web and mobile browsers. When running in-browser tests, the parking lot URL can be used to run tests directly on mobile devices. Both in-browser and WebDriver scenarios can be executed on mobile browser emulators in a cloud-based browser farm.
Do the Ext JS applications being tested need to be compiled with Sencha Cmd first?
In order to write unit tests for Ext JS applications, the app must be built with Sencha Cmd. A development build using Sencha Cmd must be performed on the Ext JS code before executing unit tests. For end-to-end tests, this does not apply. End-to-end tests are black box tests that are written once the application is deployed on a server. At this point, Sencha Test interacts with the application as a real user would and does not expect the application to be built using Cmd.
Can you test images in an app using Sencha Test?
The Sencha Test API “ST.screenshot” can be used to perform tests on images. The API allows you to create a baseline image of the viewport and compare it with images created in subsequent runs. Any discrepancies in the images will be caught by this test.
Sencha Test is designed to work with Ext JS applications. The APIs are created to work seamlessly with Ext JS components, but there are generic APIs that work with any web application. These APIs allow tests to interact with any element in a web application, and the screenshot APIs allow you to perform visual testing.
Not all browsers render the DOM in the same way, so don’t you still have to write browser-specific tests?
Sencha Test handles most of the browser-specific requests by itself. Tests can be executed on multiple browser-OS combinations without modifying the scripts. If there are browser-specific tests, these can be handled by creating conditional scripts. The ST.browser API specifically allows tests to identify the browser currently being used and perform specific operations on them.
How do you indicate/record whether the script passed or failed? How do you view/manage which scripts passed or failed and the reason for failure? Can this verification be done only for screen-based results or also for presence or values of data within the database or log files, or a combination of each?
In Sencha Test, results are displayed in a matrix format giving you a simpler way to assess application performance across multiple browsers instantaneously. The results can be interpreted in two different ways:
- API Methods: Sencha Test APIs prefixed with ST provide you with a simpler way to write tests. The APIs provide many methods that allow you to perform operations on a component or on an element.
ST.element('@some-div'). click(10, 10). contentLike(/hello/i);
For example, the above API call clicks on an element and verifies whether it contains the text “hello”.
- Jasmine Matchers: Jasmine matchers provide a simple way to compare an expected result with actual results. The matchers allow you to perform many forms of evaluations such as checking for a specific value in a text field, a grid, or looking for text on the page, etc. The matchers along with the Sencha Test APIs provide a very powerful way of writing automated tests.
Is Sencha Test primarily intended for use by the app dev team using CI as opposed to use for product test phase or stress testing? If yes, does it support those later lifecycle test phases?
Sencha Test is designed to help developers and test automation engineers create, debug, and automate tests that are tested over multiple releases across different browser-OS combinations. The higher percentage of automating test coverage of most features helps teams release apps with much better quality. Teams can maximize the use of automated tests by integrating the tests with CI tools.
Does the event recorder need to be used to re-record each time there is a functional screen change in order to test those new features? Will the existing recorded script still work with the new screen, but simply not test the new features?
Recorded test scripts will work with screen changes as long as the target locators don’t change when new features are introduced. Also, keep in mind that the recorded scripts follow a flow based on the actions that are performed on the application. If a feature modifies this flow, the test case needs to be updated with the modified workflow. Having said that, using Sencha Test APIs along with higher level test design strategies to target specific shorter workflows will help alleviate the problem of new features interfering with existing tests.