Learn how Sencha Test helped profiq, a software engineering service provider, to automate and track verification of modern Ext JS applications and their various components on multiple web browsers and devices. You will also learn tips and tricks that can speed up the development cycle of your JavaScript applications, including how you can leverage Sencha Test and its APIs.
How Sencha Test Helps Automate Functional Testing of Ext JS Apps
1. Case Study:
How Sencha Test Helps Automate
Functional Testing of Ext JS
Modern Apps
Rastislav Kanócz, CTO, profiq
Jakub Janoška, software engineer, profiq
2. Testing of modern Ext JS applications
• Run modern applications anywhere, test everywhere
• Many test frameworks available, which one to use?
2
3. Presentation objectives
• Case Study: How SenchaTest helped us to automate functional testing of Ext
JS Modern apps
• Demo
• Tips
3
4. The case
• Sencha’s Ext JS modern framework (demo: Ext JS Calendar)
• Tested on multiple devices in parallel
• Tested on multiple web browsers in parallel
• Tested and Test results tracked and stored daily
4
5. Sencha Test for Ext JS modern apps
• Fit for the purpose
- Unit and end-to-end functional testing tool
for Ext JS applications
- Rich set of powerful APIs
- Comprehensive test reporting
5
6. Sample code for selection of row in dataview:
describe('Email list', function(){
describe('email selection', function () {
it('should select 3rd row when clicked on 3rd email', function () {
if(Email.isPhone) {
ST.dataView('inbox')
.visible()
.itemAt(2)
.click()
.selected()
.dataView()
.and(function(view){
var selValue = view.getSelection().get('from');
expect(selValue).toBe('Tammi Merrill');
});
}
});
});
});
Demo I. – test on any device
• Execution of tests on connected
devices
- SSID: SenchaCon-profiq
- http://demo.profiq.com:8800
• Run tests via GUI
• Showing a code sample
• Going through test results
8. Demo II. – Integrated test environment
• Execution of tests in the cloud
• Continues integration
• Running tests via CLI (STC)
• Storing test results
8
9. Sencha Test code:
ST.grid('searchusers grid')
.rendered()
.rowAt(order)
.click()
.and (function(row){
selectRow = row;
})
.grid()
.selectedAt(order)
Selenium webdriver + python:
def test_selectRow(self):
self.browser.find_element_by_xpath("//span[contains(text(), 'User Result')]").click()
WebDriverWait(self.browser,
5).until(EC.visibility_of_element_located((By.XPATH,"//div[contains(text(), 'Alma
Allen')]")))
record = self.browser.find_element_by_xpath('//div[@class="x-panel user-grid x-
tabpanel-child x-panel-default x-grid"]//table[' + str(order) +']]')
record.click()
try:
record.get_attribute("class").index("selected")
except ValueError:
self.fail ( "not selected" )
…
Tip 1 - Effectiveness of testing
using Sencha Test
• Built-in support for modern Ext JS
components
- See code example
- Rich and extensible APIs
• Ext JS aware Event Recorder
• No config. outside of tool required
• Simple flow to configure test
execution
• Connecting all devices and
emulators via Parking lot
10. Tip 2 – Test development
• Built-in support for test debugging available
- Single spec level
- Debug console hook
• We use it to develop tests supporting
multiple platforms and troubleshoot
issues
• In case APIs for latest components are
missing we suggest implementing using
ST.element(), ST.component()
10
11. Tip 3 – Test execution
• Real HW vs. parallel
Cloud base execution
- 5x longer test execution
time for mobile emulators
in Browser Farm vs. real
mobile devices
- Make use of
Concurrency config for
parallel test execution in
Browser Farm
11
• Tests do not execute
on mobile devices
when those enter to
sleep mode or get
locked
- Turn off sleep mode and
PIN lock
• Screen comparison
tolerance too
sensitive
- Tests failing even on 1px
difference
• Still very useful for us to
uncover CSS style or
Charts (Ext JS 5+
canvas based) type of
issues
… and many more …
12. Tip 4 – Cost / Value
• Scope
• Value proposition
12
TESTS SPECIFIED TESTS AUTOMATED
TEST AUTOMATION
RATIO
Sencha Ext JS modern 338* 168 50%
Sencha Ext JS classic 623* 60 10%
DEVELOPMENT
EFFORT
MAINTENANCE
EFFORT / MONTH
MANUAL WORK
SAVED / MONTH
RETURN ON
INVESTMENT
Sencha Ext JS modern 150 Days 2 days 30 Days within 5 months
Sencha Ext JS classic 20 days 1 days 6 days within 4 months
* Complete set of tests being executed on multiple platforms (all supported web browsers, multiple types of mobile devices)
13. KEY TAKE AWAYS
• Sencha Test is the right fit for Functional testing of Ext JS applications
• Easy to setup and get started for developers and test teams and even in CI
environment
• Good Return on Investment, if automation
used on the long run
13
14. 14
Thank you for your attention!
rastislav.kanocz@profiq.com
jakub.janoska@profiq.com
15. Please Take the Survey in the Mobile App
• Navigate to this session in the mobile app
• Click on “Evaluate Session”
• Respondents will be entered into a drawing to win one of five $50 Amazon gift cards
16.
17. Tip 3 – Screen comparison – UI testing
• Used for CSS type issues and charts verification
• Built-in support in Sencha Test brings
- More efficient test execution
- Easier issues analysis
- Decreased test maintenance
17
Expected Actual Difference
Hinweis der Redaktion
Has anyone of you ever used the big pump? If yes, you probably know that it’s pretty simple to inflate the tire.
On the other hand, have you ever needed to use a small one when you got a flat tire? So you know the difference. With the small one, it’s pretty difficult to make it right, takes a lot of effort and you might get even frustrated.
And here is the association:
- We are now in the world of modern Ext JS apps. Those need to run anywhere on any device, hence we need to be able to test them anywhere which makes test scope huge.
Testing it manually would be impossible , so automation is one of the obvious answers to that. But which tool shall we use?
You have couple of test automation frameworks supporting testing of JS apps, but with regards to testing of modern Ext JS apps those are small pumps, difficult to automate testing and it takes too long. But for our purpose we found a big pump, Sencha Test, the tool, that helps us to be pretty efficient in automated test development as well as testing of these modern Ext JS apps.
Sencha Test is out for about 9 to 10 months, so we would like to share with you our experience we have with it. We hope you find here something of an interest to you, maybe a case you are trying to resolve or an idea that you could pursue farther.
This presentation is going introduce Sencha Test through a case study: How SenchaTest helped us to automate functional testing of Ext JS Modern apps
Besides showing, how we use Sencha Test in practice, we are going to show a demo and provide couple of tips for using Sencha Test too.
During demo, if anyone is interested to see running functional testing using Sencha Test on his own device, being it laptop, tablet or mobile, please be ready.
Here comes description of the case:
We are testing Sencha ExtJS components both modern and classic through Ext JS samples. One of such sample is Ext JS Calendar example.
We are testing though GUI in the browser on desktop or mobile devices such as tablets and smartphones
Builds are produced daily and bug fix rate is very high. We have a huge scope that needs to be tested really often. Manual testing can’t solve this.
There are multiple ways we use to reduce the test scope. Automation is one of its key elements.
For the purpose of automation we selected Sencha Test which perfectly fits this picture.
Due to the scope each automated test needs to support wide range of platforms, so it’s not only about coding the test, but also making sure it runs reliably on multiple browsers and range of mobile devices.
As there are many platforms where those apps can run and need to be tested we get good overview of test results with pointers to potential issues for us to work on and troubleshoot.
Sencha Test has been presented on SenchaCon already. We are not going into presenting it in detail again. This is just a high level introduction for people, who didn’t attend that session.
ST is Unit and end-to-end functional testing tool for Ext JS applications with rich set of powerful APIs and comprehensive test reporting.
We have Sencha Studio, which is an Electron based application, where Electron provides runtime environment where Ext JS components live and together with Sencha Test Command interface and Archive Server for storing logs, make out Sencha Test.
ST supports testing in multiple web browsers on multiple devices of all major players such as iOS, Android
And we are coming to the first demo here. Those that wants to see running automated tests on their device, laptop, tablet or mobile phone, please connect to this wifi … , open your browser and connect to this URL. Do not forget port there. So write demo.profiq.com, double dot and port 8800 and let it be open there.
You should see similar page loaded (OPEN PARKING LOT IN BROWSER AND SHOW)
So while the page is loading for you, let me hand it over to Jakub, who will walk you through this first demo.
Jakub stage is yours.
The previous demo has shown execution of tests executed through the Sencha Studio triggered by engineer. Now we’ll show you how we implemented automated testing into our CI to run tests regularly (daily/after each pull request/before release) in all supported platforms.
This is how the process works.
ASSUMPTION: TeamCity already ensured the build of the Ext JS app and its deployment on the Application Server.
TeamCity initiates testing through Sencha Test Command (STC) on a regular basis (for example nightly in our case). The process could be triggered by a scheduler or hooked to a pull request of the source control system.
Sencha Test spins off a browser instance from the cloud environment (we use SauceLabs) for each supported browser and opens the Ext JS application on each device/browser.
Each device/browser loads Ext JS app based on the requested URL. STC initiates testing.
STC collects individual test results and
sends them back for consolidated reporting in TeamCity and stores them in Archive server
10 minute demo follows
End to end process
The parallel test execution seen on 2 different browsers next to each other on the screen.
Consolidated test report shown.
1. Show Sencha Studio
2. Show TeamCity
This is TeamCity – continuous integration tool. We are going to run the same test set as previously on 5 different devices and browsers at same time
3. Show config for SauceLabs
We will run tests in Chrome, Firefox - This is the configuration for SauceLabs in Sencha Test that is responsible for executing tests in cloud environment
4. Switch back to TeamCity
Ok, it’s time to start testing - there is no scheduled test run right now so kick it off manually [Start Calendar test - show test progress in TC]
5. Run tests (~ 2:30)
6. Test finished
We can check results now - as you can see we can open via TeamCity as well as via Archiver
Thank you Jakub for a nice demo. I hope those practical demos were interesting to you. Now let us give you a couple of findings and tips that we came across during our use of Sencha Test.
Build-in support for Ext JS components allows test automation engineers to work at the same level as Ext JS developers, without running into unreadable xpath or DOM queries.
Code we need to write is much shorter when you use Sencha Test APIs comparing to tools without native Ext JS support.
You can control and interact with variety of Ext JS components using rich ST APIs.
Same applies for Event recorder - you are not confused by dynamic ID's and confusing xpath queries although in most cases we write the code directly.
All the required configuration can be done from Sencha Studio so you do not need to edit config files in text editors.
Tests can be executed in few clicks - you just need to set your app's URL, choose browser you want to run tests in and hit the run button.
Then testing your app on different platforms is as easy as opening single URL in desired browser. We connect multiple devices and browsers, which are immediately available in the test runner for test execution with no need for additional setup.
We usually need to re-run tests during functional test development as well as during reproducing and troubleshooting issues. Using ST this can be done by single click without need to interact with target test device.
Having ability to re-run tests (even to the level of single spec) as well as hooking tests into debug console helps us to easily troubleshoot issues while developing tests for multi-platform environment.
Many more tips:
Develop your tests as an atomic test files, so there are no dependencies between test files. Use beforeEach(), afterEach() to init and tear down. Use 5-10 assertion in a test file.
Beware of focus() issues. It might happen that your tests will fail if you minimize browser window and will report issue with focus as in these GUI tests focus is expected. Do not minimize your browser window. If you have continues integration server, have dedicated machine.
You can use your colleague’s machine if you need to test something on platform you do not have or it takes times to prepare such environment. Example you run Windows machine and your colleague has Mac and you need to check something on Safari. Just ask your colleague to open parking lot on Safari, his machine automatically appears in Studio and you can start your tests. He can continue working. Only his CPU might go higher, so be sure to warn him
The automation looks nice. But is it worth the cost? Here are two practical examples. Sencha Ext JS modern and classic toolkit components of the framework.
Scope
We designed 338 manual tests, automated 168 of them (50%) for modern toolkit.
We designed 623 manual tests, automated 60 of them (10%) for classic toolkit. In fact we have 65% of tests automated, but we used different tool. Since we switched to Sencha Test we automated 10% of tests, hence you see 10% in the table.
Each test consists of multiple steps and actions. It is complex in a way that it is not enough just to code it, but also to make sure it runs on all supported platforms – show example of KitchenSink TreeList tests
http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/?modern#tree-list
https://github.com/sencha/SDK-Test/blob/6.1-qastaging/senchaTest/test/modernKS/Trees/TreeList/TreeList.js
Value proposition
These figures were recorded towards the end of last release. At a time, when the test suite was often used.
Development effort = the time it took to develop the automated tests
Maintenance effort = the time we have been spending per month to update, refactor these tests
The set of test was developed by junior test engineers under the leadership of senior ones
Manual work saved = human effort that we would have to make, if we had no automation
ROI = the time for the to cost/value break-even
We use these tests for 8 months (classic) and 2 month (modern) now and expecting to use (and extend) them without major refactoring for min 1 year, ideally much longer
If you need help with Sencha Test, please stop by. We are going to be here for 3 days, you can find us here etc…
For cases where we need to verify UI screens, sometimes we run into issues when for example CSS styles are not rendered properly. In such cases functional test might be all passing, because UI elements are functioning properly and visual discrepancies would not be detected.
Another case is when you are trying to verify functionality of Charts. Since Ext JS 5 when Charts have changed to canvas solution it’s not possible to identify individual elements within canvas as it appears to be one object. For that we used to use Selenium with custom python libraries with screenshot comparison solution to test and verify charts. With ST we have this available within the single tool which helps us to have more efficient test execution, easier analysis of issues as well as decreased maintenance since we do not need to maintain separate code base with separate tool.
One thing that we see that could be improved is Screenshot results tolerance. With version 1.0.3 it’s not possible to specify sensitivity to image difference, so when Actual and Expected results differ, then test fails. Sencha is working on improvement where you would be able to set % (such as 97% of similarity) o consider test as passed. It’s still very useful for us as we have ability to review any differences between expected and actual and decide whether it’s ok or not.