Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Siesta Deep Dive

Avatar for Mats Bryntse Mats Bryntse
June 03, 2015
330

Siesta Deep Dive

From SenchaCon Roadshow 2015

Avatar for Mats Bryntse

Mats Bryntse

June 03, 2015
Tweet

Transcript

  1. 1 @Bryntum Siesta Deep Dive Improve the quality of your

    Ext JS app releases with unit & UI tests
  2. Agenda 3 Siesta News Unit & UI tests •Recently added

    features •What’s new in Siesta 3.0 •Feature walkthrough •Application tests •Continuous Integration •Tips & Tricks •BDD / TDD •Using PhantomJS •Testing a view App tests & CI
  3. Recent Siesta features 5 • sandboxing now optional • async

    setup/tearDown test methods • taking screenshots • event recorder improvements & configurability
  4. 7

  5. 9 describe(‘Some spec', function (t) {
 var component; t.beforeEach(function(t) {

    component = new Ext.Component(); })
 t.it('Should test something', function (t) {
 });
 }); beforeEach/afterEach
  6. …and more 11 • Improved memory management • Tests can

    now run in popups instead of iframes • Touch event support • Jasmine style spies
  7. 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 29
  8. 30 describe('A simple Model test', function (t) {
 
 


    t.it('Should do something', function (t) {
 var user = new User({ name : "Bob" });
 
 
 t.expect(user.name).toBe("Bob");
 
 });
 }); Simple BDD unit test
  9. 31 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
  10. Unit tests are your friend 32 • 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
  11. TDD basics 33 1. Make the unit test fail 2.

    Implement 3. Make the test pass 4. Refactor, Repeat
  12. 36 • UI unit test of a single UI component

    • Or application test, open index.html and test it Two main types of UI tests
  13. Application testing 43 • Aka black box testing, functional testing

    • Go to application index.html • Runs all the code of your application • Does app work or not?
  14. Challenges 44 •Database needs to be put in a known

    state •Slow •Tests can become fragile, race conditions •Errors likely harder to find
  15. 46 • Great for application tests • Records user actions:

    clicks, types, drag drop • Can be used by a non-programmer • Big timesaver Using the event recorder
  16. Monkey testing 49 • Random UI testing • Clicks, drags

    etc. in your UI • Finds unhandled exceptions • Free testing help. 0€
  17. Purpose of CI 53 • Automated builds • Nightly test

    suite execution • Finding errors early => Code quality => Motivated developers • Enables Continuous Delivery
  18. 55 • Bryntum uses TeamCity • Test suites run every

    2 hours in Chrome • Nightly for all other browsers • Reports, statistics, charts and code coverage
  19. X-browser testing 58 •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
  20. 59 • Siesta integrates with both BrowserStack and 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
  21. 63

  22. 68 Testing different screen sizes {
 name : 'Responsive app

    test - landscape',
 viewportWidth : 1024,
 viewportHeight : 768,
 hostPageUrl : 'executive-dashboard/',
 url : 'executive-dashboard/tests/large-size.t.js'
 },
 {
 name : 'Responsive app test - portrait',
 viewportWidth : 500,
 viewportHeight : 700,
 hostPageUrl : 'executive-dashboard/',
 url : 'executive-dashboard/tests/small-size.t.js'
 }
  23. Summing up 71 • Prioritise JS unit tests • Don’t

    forget UI tests • Application & monkey tests • Continuous Integration • Tips for finding errors early