Unit and UI Testing Your Ext JS Web Applications with Siesta

Testing a large Ext JS application code base can be challenging. Running your tests across multiple platforms and browsers is also a bit of a pain. The good news is, there are many great tools out there that will make your life as a developer (and tester) easier.

Transcript

1. @Bryntum Unit and UI Testing Your Ext JS Web Applications with Siesta
2. Mats Bryntse Founder, Bryntum Stockholm, Sweden
3. 3 •Team of Sencha community members since 2007 •Powerful Gantt & Scheduling charts for Ext JS •Testing and monitoring tools •Training / Consulting •2000+ clients in 70+ countries
4. Agenda 4 Siesta Intro UI tests •Feature walkthrough •Writing good tests •Basic unit test •Using PhantomJS •Application tests •Recorder •Continuous Integration •Simulating actions •Testing a view •Custom Test Class Application tests
5. Siesta Introduction
7. 7 • Siesta handles Unit, UI + Application testing all in one tool • Tests any JS code base • Siesta is web based, extensible • Special testing layer for Ext JS Overview
8. 8 • Tests are written in JS in “plain” style or BDD • Tests run completely isolated in iframes • Powerful event recorder • Code coverage • You can extend Siesta and add own assertions or helper methods Test features
9. 9 • Report generation (HTML, JSON, XML) • Integrates easily with TeamCity, Jenkins, and more • Integrates with cloud testing provides such as Sauce • Supports parallel test execution Automation features
10. Unit Tests Red, Green, Refactor
11. 11 Terminology: What does testing mean for a JS developer?
12. 12 Unit tests, UI tests, Application tests..?
13. Ideal Test Pyramid 13 JS Unit tests App Tests View tests
14. Real World 14 Backend unit tests App Tests
15. A unit test • should focus on a single JS class (“unit”) • should not involve DOM • is pure logic, runs very fast • is perfect for pre-commit hooks 15
16. 16 describe(‘Some spec', function (t) {
 var component; t.beforeEach(function(t) { component = new Ext.Component({ width : 100 }); })
 t.it('Should test something', function (t) {
 t.expect(component.getWidth()).toBe(100) });
 }); Basic Unit Test
17. 17 describe("A simple Model test", function (t) {
 
 t.it("Will not run", function (t) {
 …
 });
 
 
 t.iit("Isolate this section", function (t) {
 …
 });
 
 }); t.iit for fast test debugging
18. Unit tests are your friend 18 • Should be your #1 priority • Cover your most important JS classes, code that is reused • Run often, before commit, daily, nightly. • Use TDD approach + BDD style for readability
19. TDD basics 19 1. Make the unit test fail 2. Implement 3. Make the test pass 4. Refactor, Repeat
20. Unit Test Demo 20
21. Writing good tests
22. Test code standards 22 • Apply same code standards for test code as for app code • Document well • Don’t overcomplicate: favour test readability over DRY • Write abstracted methods for code reuse to avoid boilerplate test code
23. Break tests into subtests 23 describe("A simple Model test", function (t) {
 
 t.it("Will not run", function (t) {
 …
 });
 
 
 t.iit("Isolate this section", function (t) {
 …
 });
 
 });
24. Minimising test maintenance 24 • Flaky tests can be hard and demoralising • Race conditions can sneak into application / test code easily • Debugging consumes time • Some guidelines tips & tricks to consider
25. Avoid hard coded waits 25 t.chain( { click : “div.loadUserButton” }, 
 { waitFor : 2000 }, // loading takes time
 function() { // Should be 10 users in grid now t.expect(userGrid.getCount()).toBe(10);
 }
 });
26. Use waitFor with condition 26 t.chain(
 { click : “div.loadUserButton” }, 
 { waitFor : function() { return userGrid.getCount() > 0; },
 function() { // Should be 10 users in grid now t.expect(userGrid.getCount()).toBe(10);
 }
 );
27. Independent tests 27 • Tests should not rely on other tests • It should always produce same result regardless of when executed • Automation mode does not guarantee test order (== good)
28. UI Testing Render, Interact, Assert
29. 29 • UI unit test of a single UI component • Or application test, open index.html and test it Two main types of UI tests
30. 30 Manually writing UI tests takes time
31. 31 UI tests are more fragile & run slower than unit tests
32. 32 Understanding CSS and ComponentQuery is key
33. 33 Reveals tight coupling very efficiently UserList.js Test sandbox Viewport.js
34. 34 t.chain(
 { click : '>>[name=name]' },
 
 { type :'Bob[TAB]' },
 
 { type : ‘Bobs password' },
 
 { click : 'div.x-btn:contains(Login)'},
 
 { waitForSelectorNotFound : ‘.loginWindow'} ) Siesta UI test format
35. 35 UI Unit test demo
36. Writing stable UI tests
37. Testing dynamic DOM apps 37 • Organisation decision: Testing must be prioritised • Code should be written to facilitate testing. • Developers should annotate DOM for easy UI testing
38. Testing dynamic DOM apps 38
39. Beware of generated ids 39
40. Not very robust… 40 t.chain( { click : “div#dataview-1076-3183” },
 …
 });
41. Better decide on a custom attribute 41 <button data-testid="theSaveButton"></button>
 <img data-testid=“userAvatar"/>

42. Now it’s very robust… 42 t.chain( { click : “[data-testid=userAvatar]” },
 …
 });
43. Application Tests Click, Wait, Assert
44. Application testing 44 • Aka black box testing, functional testing • Go to application index.html • Runs all the code of your application • Does app work or not?
45. Challenges 45 • Database needs to be put in a known state • Slow • Tests can become fragile, race conditions • Errors harder to find
46. Using the event recorder 46
47. 47 •Great for application tests •Records user actions: clicks, types, drag drop •Can be used by a non-programmer •Big timesaver Using the event recorder
48. 48 Let’s try the recorder
49. 49 Monkey testing
50. Monkey testing 50 • Random UI testing • Clicks, drags etc. in your UI • Finds unhandled exceptions • Free testing help. 0€
51. 51 5€ * 0 = 0 5€ Cost breakdown
52. 52 Monkey testing demo
53. 53 Screenshot comparison webdriver lh/siesta/tests/ --screenshot-compare-with-previous ===
54. 54 Screenshot individual elements
55. Automation & CI Team City, Cloud Services, Statistics
56. Multiple test launchers 56 • webdriver (preferred) • PhantomJS (Webkit-ish) • SlimerJS (Firefox) • xvfb (Linux, parallel test execution on local machine)
57. Purpose of CI 57 • Automated builds • Nightly test suite execution • Finding errors early => Code quality => Motivated developers • Enables Continuous Delivery
58. 58 Always ready to release!
59. 59 •Bryntum uses TeamCity •Test suites triggered by every commit in Chrome •Nightly for all other browsers •Reports, statistics, charts and code coverage
60. 60 So…running in multiple browsers?
61. X-browser testing 61 •Need to create Virtual Machines for each version of IE •Total: Chrome, Safari, FF, IE 7-11 => 5 VMs •Managing such a farm can be very time consuming
62. 62 • Siesta integrates seamlessly with Sauce Labs • Run tests easily in any OS and Browser combination • No need to setup your own VM farm • Read more on the Bryntum blog… Cloud to the rescue
63. 63 Launching tests with Sauce webdriver localhost/siesta/tests --saucelabs
64. 64 Running tests in parallel test1.t.js test2.t.js test3.t.js test5.t.js test4.t.js
65. 65 Parallel tests with Sauce webdriver localhost/siesta/tests --saucelabs --max-workers=20
66. Summing up 66 • Prioritise JS unit tests • Don’t forget UI tests • Application & monkey tests • Continuous Integration • Automate!
67. Links 67 • bryntum.com/products/siesta • bryntum.com/blog • teamcity.bryntum.com/guest • saucelabs.com/
68. 68 Meet us in Las Vegas, November 7-9 www.senchacon.com
69. 69 Questions? Twitter: @Bryntum