JS Automation brownbag

Get Started. It's Free
or sign up with your email address
Rocket clouds
JS Automation brownbag by Mind Map: JS Automation brownbag

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