Workshop Plan

[dbouwman]

Time Blocking: 8:30am --> 5:00

8:15-> 8:30: Be in the room, setting up, help people ensure they have requirements on machines 8:30 - 8:45: Intro and Logistics

• who we are
• who they are
• restrooms
• break 10
• lunch 12

Zen of Testing 8:45 - 9:15 - Dave

• why test at all?

• manual vs robots

  • people are inconsistent and cost $$
  • people are good for intl testing!

• unit vs component vs acc

• what else can 🤖 's do for us?

  • Dave has some content in "Test-Tooling.pptx"
  • check translations / lint rules
  • warnings and deprecations

• testing at scale

  • sending test output to a logging system
  • using dashboards to show trends / performance
    • faster tests === faster feedback loops
  • really useful for trends of failures (i.e what upstream systems are flaky)

• framework test strategies

  • Angular / React / Vue / Ember

• agnostic e2e

  • drives a browser
  • compariatively slow...
  • can be run against many browsers (crossbrowsertesting.com)
  • simulates real user interactions
  • flexes the whole stack
  • usually done w/ a separate QA stack

• test workflows

  • ad-hoc vs CI

Stack Review - 9:15 - 9:30 - Tate

• node + editor of choice
• webdriver.io
  • selenium + browsers
  • provides API to drive the browser, inspect DOM, make assertions
• Getting Started (walk-thru)
  • create folder
  • npm init
  • install deps
  • index.js
  • open google.com

HANDS ON: Hello-World - 9:30 - 9:45 (15 min)

• have class do the same stuff we just demoed

Tate: WebDriver 101 9:45 - 10:15 (walk-thru w/ explanations)

• super simple single file example
• walk thru the code almost a line at a time
• imports
• open google
• search for esri devsummit workshops
• get first entry
• ensure a tag has -> "Pre-Summit Hands-On Training | 2020",
• click link
• expect url to be https://www.esri.com/en-us/about/events/devsummit/agenda/pre-summit-hands-on-training

BREAK: 10:15 - 10:30

HANDS ON: 10:30 - 11:00 (30 min)

• class does the WebDriver 101

Dave: Going Deeper & Page Model 101 11:00 - 11:30

• locate the course entry
• Look at the DOM - we see big set of <div's uh-oh...
• to get our course we'll need to use a n-th selector
  • in apps you control, it's preferable to add data-test attrs enabling you to locate content
• event-detail-registration_heading
• current code is getting messy
• we've opened two pages (google and the event page)
• we have selectors + assertions all mixed up
• scaling this up is unsustainable
• Enter Page model
  • present details on this...
• Add simple page models to the 101

HANDS ON: 11:30 - 12:00

• class does the Page Model exercise

Lunch: 12 - 1

Real-World E2E Projects 1:00 - 2:00 (Talk) Dave & Andew split

• run test automatically if possible (CI)
• on failure, give good messages
• organize code to make specs easy to write and easy to debug
  • Pages and Components and Flows
• handling credentials with dot.env
• run test as multiple types of users
  • different types of users, orgs etc
• abstraction of the what vs the how
• where to put assertions
• validating non-visual changes
  • pattern - connect to data store and verify directy
  • arcgis-rest-js integration

DEMO: Hub E2e Tour + Run

• talk about hub a little
• size of app
• testing strategy
  • lots of unit, less component, less acc, less E2e
• run at crossbrowsertesting.com
• run a subset of tests just to watch it
• Target 30 min

HANDS ON: TODO: Add details for what this is

• goals

  • work with something that has data-test attrs
  • do something w/ rest-js to verify state of something

• use the react react app from prev day workshop

  • dave to host

• show how we've added data-test attrs to make things easier

• use multiple pages

• show how we use fixtures / well-known routes to items

  • use rest-js to create an item, then search for it, verify props in ui, delete item

Testing w/ AGO

• oAuth patterns
  • pop-out oauth vs full-page transition flow
    • why one vs other?

Chicken & Egg Problem

• how do you write e2e tests for code that's not yet deployed?
• have a staging environment

Wrap up:

• ??

[drewdaemon]

Very thorough, Dave. Nice work.

Some thoughts:

• with the zen of testing, this article from the google testing blog could be helpful, especially the "testing triangle," which visually illustrates that unit tests should form the foundation of the testing strategy, with integration tests built on top, and finally a sprinkling (in comparison) of E2Es.
• As far as tech stack, it makes perfect sense for us to use webdriver.io, but it might be worth me pointing out that there are other possibilities as well and encourage them to evaluate the technologies based on their needs.
• re: how do you write e2e tests for code that's not yet deployed? I think it makes sense to talk about a staging server (and even making it as hermetic as possible). But, most teams will also be able to run them locally/containerized which is also worth pointing out.
• Could also be cool to demo some of our more impressive tests. I think seeing that browser window open and crank through Hub would really help people get excited and catch the vision.

[drewdaemon]

This might be an interesting page to point them at as a "go build your own tests" parting pointer: https://webdriver.io/docs/boilerplate.html

It features starter code for lots of different possibilities (various test frameworks, and also Typescript).

[dbouwman]

Another resource --> https://medium.com/better-programming/what-not-to-do-when-writing-e2e-tests-ef7b9d09cc81 (have not read yet)