1. What does automation do
1.1. Run UI tests on android
1.1.1. Saucelabs
1.1.2. Emulators
1.2. History
1.2.1. Started as a POC for JS feasibility
1.2.1.1. based off saucelabs sample code
1.2.2. Supported both iOS and Android with same test cases
1.2.3. Supported v1 mocking service
1.2.4. Started Entirely using ES5 and promise chains
1.2.4.1. Still some tests use them
1.3. Contributors
1.3.1. Me
1.3.2. Kumar
1.3.3. Pani
1.3.4. Sadaf
1.4. Able to run tests in parallel
1.4.1. across a test run
1.4.2. multiple runs at the same time
1.5. Screenshots for android play store on all languages
1.5.1. could use fastlane as alternative
2. appium
2.1. node js based server
2.2. open source project with a lot of history and contributors
2.2.1. their project was here friday
2.3. Recently made the move to ES6 and a big refactor modularizing a lot of legacy JS code
2.3.1. from
2.3.1.1. https://speakerdeck.com/jlipps/how-to-become-an-appium-contributor?slide=18
2.3.2. BEFORE
2.3.3. After
3. Areas of improvement
3.1. Move to ES6 syntax completely
3.1.1. Use a linting
3.2. Global setup.js
3.3. Using GLOBAL scope for driver and other constants
3.3.1. driver
3.4. Extra shot
3.5. Page object
4. Grunt tasks
4.1. Started using for running tests in parallel
4.2. Configured to make running tests configurable
4.3. Using mocha-grunt plugin
4.4. Running tests in OS, screensize etc
4.4.1. Running OTE tests
4.4.2. Running tests on sauce
4.4.3. Running tests locally
4.5. Minimal configuration in Jenkins
5. Neat things (not really JS related)
5.1. Using API for verifications
5.2. Mock service
6. Mocha
6.1. artificial tags
6.1.1. running a group of tests
6.2. it
6.2.1. bdd syntax
6.3. beforeEach/afterEach
6.3.1. Root hooks
6.4. skip/only
7. ES6 setup
7.1. babelrc
7.2. Motivation
7.2.1. Breaking out of the promise chains
7.2.1.1. async/await
7.2.1.2. wd chain
7.3. dist, src folder
7.4. Grunt task for compiling
8. sauce setup
8.1. bash_profile variables
8.2. capabilities
8.2.1. Tags for easy searching
8.2.2. Build name for proper display in dashboard
8.3. Beforeeach test getiting the name
8.4. Aftereach test updating status of test
8.5. Uploading apk through grunt task
9. Test best practices
9.1. Phases of test
9.1.1. Setup
9.1.2. Action
9.1.3. Assert
9.1.4. Cleanup
9.2. Verify one scenario in one tests
9.2.1. Not necessarily one assertion
9.3. Test names to be very descriptive and english like
9.3.1. appending language at the end
9.4. Test Automation is code - follow software best practices
9.4.1. Componentizing
9.4.1.1. Page objects
9.4.1.2. Action helpers
9.4.2. DRY
9.4.2.1. Don't repeat code, move to appropriate helper functions
9.5. Don't sleep
9.5.1. Wait for something to show up/disappear
9.5.1.1. Progressbarinvisible
9.5.2. Utilize the implicit timeouts given by test framework
9.6. Seperate out data and test logic
9.6.1. Both should be independent
9.7. Seperate out UIView and test code
10. Challenges for UI automation
10.1. UI tests aim to mimic user behaviour in a real world situation - they cover scenarios
10.1.1. Real world
10.1.1.1. Is not entirely controllable
10.1.1.1.1. networks
10.1.1.1.2. api flakiness
10.1.1.1.3. env flakiness
10.1.1.2. varying performances at various layers
10.2. tests are not intelligent
10.2.1. They perform actions that they are programmed for
10.3. mobile UI automation is even harder
10.3.1. Have to create a framework agnostic to iOS/Android
10.3.2. have operate in walled garden of apple/ios
10.3.2.1. use their tools under the hood
10.3.3. tool support still maturing
10.3.4. debugging failures much harder on cloud emulators/devicesf
10.3.5. http://sauceio.com/index.php/2016/04/mobile-vs-web-which-is-harder-to-test/
10.4. Failures are not consistent
10.4.1. intermittent is the word of the day