I'd like to be able to do key combos using browser.sendKeys() and the Key enum to simulate typing on a keyboard.
Additionally I need to send different key combinations depending on the platform the test script will run on.

Command-Key combos might not be possible on mac, but there are still plenty of web-apps which handle keyboard input directly for key combos.
puppeteer/puppeteer#1313

When developing the test script using Element on my Mac I'd copy something with CMD-C, but when the script runs on flood.io it'll be running under linux, where the equivalent combo is CTRL-C. This point may be moot depending on puppeteer#1313

A simple API would be to allow grouping sendKeys inputs into arrays: browser.sendKeys( [Key.CONTROL, "A"] ) would press CTRL-A

Not all keys listed are included in the Key enum

Describe the bug

'UPDATE AVAILABLE' The latest version of Element CLI is 1.0.7
Get it by running yarn global upgrade @flood/element-cli@latest
+0s info: workRootPath: /work/git/OKR/main/flood/tmp/element-results/filename/2019-08-04T113415.401Z
+0s info: testDataPath: /work/git/OKR/main/flood
Error! An unexpected empty rejection occurred
rejection: null
this is a bug, please report it here https://github.com/flood-io/element/issues/new?template=bug_report.md

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Mac OS
• Node.js version: v12.3.1
• Version [e.g. 1.0.2]

Additional context
Add any other context about the problem here.

Implement init command for generating a fresh test project with sane defaults on package.json, tsconfig, layout, etc

Currently, step labels are set on script load when we evaluate the script. We use the label from the first argument to the step() function.

It would be useful to be able to change this at runtime, in order to indicate what happened in the report.

Possible implementations

this.label = "foo"

This would work by introducing a local scope to steps (currently null) during runtime. The local scope would expose one writeable property: label, which ordinarily resolves to the name of the step.

After the step runs, the value of label is written to a property called label on the Step object and used in reporting.

Interpolation

This method would work by interpolating strings in the step title using test data properties.

type Row = {itemName: string}

step("Item: {itemName}", (browser, row:Row))

Limitation here is that you could only do it using test data, and not any string computed within the step. This is largely ideological, how much do we want to allow customers to do that?

Rework the VM

Last approach would mean redesigning the VM so that we can eval steps at runtime. There are obvious reasons this isn't ideal.

Maybe use watchman or nodemon under the hood.

Is your feature request related to a problem? Please describe.
It would be nice to have the ability to add custom HTTP Headers - i.e to be able to follow different client flows for an A/B test as well as setting different Headers for other testing/environment config purposes.

Describe the solution you'd like
It would be great to be able to add/set custom HTTP headers globally and/or on a step basis.

Something like .setExtraHTTPHeaders in Puppeteer: https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#pagesetextrahttpheadersheaders

**Is your feature request related to a problem? No, it's a feature request

Describe the solution you'd like
Ability to handle Javascript alert windows with Flood Element

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

It would be great to run small-scale load tests locally using element scripts. We've also considered just writing vanilla pupetter scripts and using something like https://www.npmjs.com/package/puppeteer-loadtest.

Does the element CLI support running multiple instances of a script locally in parallel?

Describe the solution you'd like

An option to configure running tests in Incognito mode so that all profile session data is reset each time.

Describe alternatives you've considered

Clear session/cookies/cache doesn't work because some profile data can still remain in other databases/localstorage.

I have not been able to find any documentation around specifying the chrome version. The documentation I found referenced --chrome-version, which I don't see available when running element run help. I only see --chrome, which specifies which version of chrome to use. However, I'm not sure what type of input is expected? Could you please point me in the right direction?

Thanks,

Describe the bug
When trying to use https module, getting:

{ VMError: Access denied to require 'https'
    at _require (/usr/local/Cellar/element/1.0.4/libexec/lib/node_modules/@flood/element-cli/node_modules/vm2/lib/sandbox.js:195:13)
    at Object.<anonymous> (/var/folders/7l/qqghyvjs20g587ptb1590_3h0000gq/T/flood-element-tmp/test-script-sandbox/flood-chrome.ts:5:15)
    at NodeVM.run (/usr/local/Cellar/element/1.0.4/libexec/lib/node_modules/@flood/element-cli/node_modules/vm2/lib/main.js:419:27)
    at EvaluatedScript.evaluate (/usr/local/Cellar/element/1.0.4/libexec/lib/node_modules/@flood/element-cli/node_modules/@flood/element/src/runtime/EvaluatedScript.js:156:30)
    at new EvaluatedScript (/usr/local/Cellar/element/1.0.4/libexec/lib/node_modules/@flood/element-cli/node_modules/@flood/element/src/runtime/EvaluatedScript.js:42:18)
    at testScriptFactory (/usr/local/Cellar/element/1.0.4/libexec/lib/node_modules/@flood/element-cli/node_modules/@flood/element/src/Element.js:55:16)
    at <anonymous> name: 'VMError', code: 'EDENIED' }

To Reproduce
import * as https from 'https'

Expected behavior
Able to import https

Screenshots
N/A

Desktop (please complete the following information):
N/A

Additional context
Wanted to post some metrics directly to DataDog API.

By.attr takes three formal parameters your documentation example suggests two arguments.

https://element.flood.io/docs/1.0/api/Locators

By.attr('name', 'frame-name')

Benefit:

Make it possible to include external node packages in the test VM at runtime.

Technical considerations

• Refactor the compiler to support loading packages
• Run npm install in the sandbox directory
• Allow uploading a package or syncing from GitHub
• Compile everything into the VM

To make it easier for people to contribute, and maintain a consistent code base, I think we should consider adding some code formatting rules via Prettier.

Some configuration rules exist in the package.json file, but I'd like to set this up to run as a pre-commit hook rather than relying on editor plugins.

Adding linting might also be nice, although that might be redundant with the TS compiler—interested on opinions about this one.

Describe the bug
After installaing with "npm install -g @flood/element-cli" and running "element init" results in permission error

To Reproduce
Steps to reproduce the behavior:

1. run "npm install -g @flood/element-cli"
2. run "element init
3. See error:
   Chriss-MBP:flood cvalcourt$ element init riv --verbose

Error! An unexpected error occurred!
Error: EACCES: permission denied, mkdir '/Users/christopher'
at Object.fs.mkdirSync (fs.js:885:18)
at make (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/make-dir/index.js:61:12)
at Function.module.exports.sync (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/make-dir/index.js:84:9)
at TestEnv.destinationRoot (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/yeoman-generator/lib/index.js:644:17)
at TestEnv.initializing (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/dist/src/generator/test-env/index.js:22:14)
at Object. (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/yeoman-generator/lib/index.js:424:27)
at /Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/run-async/index.js:25:25
at new Promise ()
at /Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/run-async/index.js:24:19
at self.env.runLoop.add.completed (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/yeoman-generator/lib/index.js:425:13) Error: EACCES: permission denied, mkdir '/Users/christopher'
at Object.fs.mkdirSync (fs.js:885:18)
at make (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/make-dir/index.js:61:12)
at Function.module.exports.sync (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/make-dir/index.js:84:9)
at TestEnv.destinationRoot (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/yeoman-generator/lib/index.js:644:17)
at TestEnv.initializing (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/dist/src/generator/test-env/index.js:22:14)
at Object. (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/yeoman-generator/lib/index.js:424:27)
at /Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/run-async/index.js:25:25
at new Promise ()
at /Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/run-async/index.js:24:19
at self.env.runLoop.add.completed (/Users/christopher valcourt/.nvm/versions/node/v8.12.0/lib/node_modules/@flood/element-cli/node_modules/yeoman-generator/lib/index.js:425:13)
this is a bug, please report it here https://github.com/flood-io/element/issues/new?template=bug_report.md

Expected behavior
A project is initialized

Screenshots
n/a see description above

Desktop (please complete the following information):

• OS: macOS 10.14 (18A391)
• Node.js version: v8.12.0
• Version 1.0.4

Additional context
n/a

Describe the bug
Unable to install flood element on Windows 10

To Reproduce
Steps to reproduce the behavior:

1. On Win10 (ver 1703 OS build 15063.1058) with Node (v10.16.3) and NPM (6.9.0) already installed
2. Attempt to install flood element (npm install -g @flood/element-cli)
3. Error received (repro'd on 2 different machines)

$ npm install -g @flood/element-cli
npm WARN deprecated [email protected]: core-js@<2.6.8 is no longer maintained. Please, upgrade to core-js@3 or at least to actual version of core-js@2.
npm WARN deprecated [email protected]: cross-spawn no longer requires a build toolchain, use it instead
npm WARN rollback Rolling back [email protected] failed (this is probably harmless): EPERM: operation not permitted, lstat 'C:\Users\tswift\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\path-type\node_modules'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules@flood\element-cli\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

npm ERR! path C:\Users\tswift\AppData\Roaming\npm\node_modules@flood\element-cli\dist\index.js
npm ERR! code ENOENT
npm ERR! errno -4058
npm ERR! syscall chmod
npm ERR! enoent ENOENT: no such file or directory, chmod 'C:\Users\tswift\AppData\Roaming\npm\node_modules@flood\element-cli\dist\index.js'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\tswift\AppData\Roaming\npm-cache_logs\2019-09-03T20_24_35_014Z-debug.log

hi All,

Wanted help regarding one of the configurations :

1. What should be the configuration to show the response time "Step" wise in console?

2. Is there any way to exclude action delay in the final response time displayed?

Describe the bug
Unable to handle browser dialogs that do not appear in the DOM.
The Flood Element spec file use CSS selectors

I hang on replace.click() which activates the browser dialog.

    await replace.click()
    await browser.wait(Until.alertIsPresent())
    let dialog: Dialog
    await dialog.accept()

This is the example provided in your docs.

// https://element.flood.io/docs/1.0/api/Waiters
step('Handle alert', async browser => {
  let dialog = await browser.wait(Until.alertIsPresent())
  await dialog.accept()
})

accept does not have a method on a Boolean,

Is your feature request related to a problem? Please describe.
Use case is being able to run element tests with webrtc services that require the following flags set in chrome for automation: use-fake-ui-for-media-stream, use-fake-device-for-media-stream

Describe the solution you'd like
Allow users to set chromeOptions at runtime: puppeteer/puppeteer#2363

Describe alternatives you've considered
Java-based chrome

Additional context
N/A

Similar to Gatsby, it'd be really neat to be able to generate a test from a cookbook example which is a GitHub repo.

Something like:

element init my-test-name --starter=https://github.com/flood-io/cookbook/wordpress-cart-example

When I tried to run a script at the command line element exited and reported that an update was available. When I tried to update nothing happened because I already have the latest version. This update message stops me from using the element run command

To Reproduce
Steps to reproduce the behavior:

1. Run a simple script the normal way element run flooded_io.ts
2. Message comes back

> 'UPDATE AVAILABLE' The latest   version of Element CLI is 1.0.8-stable.1
> Get it by running brew upgrade element
+0s info: workRootPath: /Users/jjwelch/Dropbox/PeoplesUnited/element_poc_oao/new-account-flow-oao/tmp/element-results/flooded_io/2019-09-05T163319.696Z
+0s info: testDataPath: /Users/jjwelch/Dropbox/PeoplesUnited/element_poc_oao/new-account-flow-oao
> Error! An unexpected empty rejection occurred
 rejection: null
this is a bug, please report it here https://github.com/flood-io/element/issues/new?template=bug_report.md

3. Try to upgrade element

brew upgrade element
Error: flood-io/taps/element 1.0.8 already installed

4. Check my version

element --version
> 'UPDATE AVAILABLE' The latest   version of Element CLI is 1.0.8-stable.1
> Get it by running brew upgrade element
1.0.8

Expected behavior
Element should run no matter what version I have. Why does it not support using an older version? Why does it stop me from running due to an update available? How do I override and run it until this brew issue is fixed?

Desktop (please complete the following information):

• OS: macOS 10.13.6 High Sierra
• node --version v12.9.1
• npm --version 6.11.2
• lighthouse --version 5.1.0

Additional context
Is this a conflict with NPM? I have NPM so I can run google lighthouse at the command line. Of course, it has been working with NPM and Lighthouse for weeks so I doubt that is it.

I think this is a config problem with homebrew at the source

Describe the bug
On Mac OS High Sierra - get error when trying to use 'element init'

To Reproduce

1. On Mac OS High Sierra, run 'brew install flood-io/taps/element'
2. Run element init after install

Result:
➜ Prompt element init

'UPDATE AVAILABLE' The latest version of Element CLI is 1.0.4
Get it by running yarn global upgrade @flood/element-cli@latest
initting into /Users/elise/Repos/PluginTests
? The title of this test. (PluginTests) > Error! An unexpected empty rejection occurred
rejection: null
this is a bug, please report it here https://github.com/flood-io/element/issues/new?template=bug_report.md

Expected behavior
Expected no error! It claims I already have 1.0.4 if trying to update as well.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):
Mac OS High Sierra

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.

To increase learnability we should consider using an existing testing DSL which is familiar to a wide audience. Example, Cypress uses the Mocha style.

Describe the solution you'd like

Implement a replacement for test steps which is based on the descriptive style of Mocha:

import {describe, it} from "@flood/element"

describe("Load testing app", () => {
  describe("Login page", () => {
    it("enters username and password", async (browser) => {
      let input = await browser.findElement(By.id("username"))
      ...
    })
  })
})

Describe alternatives you've considered

There are others, TBA

Additional context

The goal of this story is to open up support for nested test steps and a more flexible testing DSL.

Add support for switching tabs or windows in much the same way we do with Frames, using the TargetLocator.

Describe the bug
When specifying a ramp-up duration within the Flood UI for a Flood Element test. It seems to get ignored.

To Reproduce
Steps to reproduce the behavior:

1. Specify a longer ramp-up of 2 minutes and kick-off a FE test through Flood.

Expected behavior
Expected ramp-up period to be users increasing over the entered 2 minute value. Instead all users are being ramped-up within 15 seconds.

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Node.js version: 11.3
• Version 1.04

Additional context
n/a

Make it possible to pass additional launch args to Chrome through the Puppeteer launch args.

Describe the solution you'd like

export const settings = {
  launchArgs: ["--proxy-server=127.0.0.1:9876"]
}

"Grid mode" includes Influx reporter & flood env var configuration/metric identifier
"Dev mode" includes Console reporter & command line configuration

e.g. env vars handled in the VM, extract to grid runner a la tosca-flood Grid/Environment.ts
https://github.com/flood-io/element/blob/feature/open-source-everything/packages/element/src/runtime/VM.ts#L188-L208

When trying to test my Element scripts in flood, if i set the responseTimeMeasurement to 'page' or 'network', as per the documentation, i get no response time, only Transaction Rate and Current Users.

To Reproduce
Steps to reproduce the behavior:

1. Set responseTimeMeasurement to 'page' in your element script
   Documentation
2. Upload the script to a Stream
3. Run a Flood

Expected behavior
I expect to see full page load times as mentioned in the documentation:

• STEP: Record the document loading response time. This is usually what you consider response time on paged web apps.

Screenshots

Code Sample:

• Test Settings:
  export const settings: TestSettings = { clearCache: true, disableCache: true, screenshotOnFailure: true, clearCookies: true, actionDelay: 0, stepDelay: 0, DOMSnapshotOnFailure: true, responseTimeMeasurement: 'page', waitTimeout: 180, }

• The Step:
  step('Test: Reach the main page', async browser => { await browser.visit(<URL>) await browser.wait(Until.elementIsVisible(Header_Icon)) await browser.wait(Until.elementIsVisible(Shop_Button)) await browser.wait(Until.elementIsEnabled(Search_Field)) await browser.wait(Until.elementIsVisible(Cart_Icon)) await browser.wait(Until.elementIsVisible(Footer_Icon)) await browser.wait(Until.elementLocated(Product_List)) })

The element command takes a few seconds on even a very fast machine to load. This is probably because of the way we package the dependencies.

We should add profiling and investigate where we're spending most of our time.

Also consider looking at compiling with ncc into a single blob.

Add support for interacting with Puppeteer Mouse events. This is required for handling drag & drop, sliders, and hover interactions.

Describe the solution you'd like

Mouse events, especially hover events, are quite verbose, I would suggest we support something which takes ...events as an input of 1 or more events.

Example:

await browser.mouse.down(x,y)
await browser.mouse.up(x,y)

// only send movement
await browser.mouse.move(x1, y2, x2, y2, ..., xn, yn)

// initiate a drag with `mousedown`, `mousemove1`, `mousemove2`, `mouseup`
await browser.mouse.drag(x1, y2, x2, y2, ..., xn, yn)

Describe the bug
When analysing an Element load test on Flood, the passed counts for the first two steps of a script show that the first step, which opens up the page, has a smaller count than the second step, which logs into the application.

To Reproduce
Steps to reproduce the behavior:
Unable to reproduce reliably.

1. Run an Element script through Flood with multiple users.
2. Check transaction details for the first two steps.

Expected behavior
The count for Step 2 is equal to or less than the count for Step 1.

Screenshots

Desktop (please complete the following information):

• OS: mac OSX 10.14.0
• Node.js version: 10.14.2
• Version 1.0.4

Loading test data assigns to the testData property, so subsequent calls to TestData methods in a script override preciously loaded data.

For example, given

TestData.fromData([ 'foo', 'bar', 'baz' ])
TestData.fromData([ 'red', 'green', 'blue' ])

the second call to fromData will override the data loaded from the first, and only red, green, blue values will be available in steps. This same behaviour exists for fromData, fromCSV, fromJSON, or a combination of any of them.

Was this an intentional design decision, or is there another API for achieving this? If so, we should document either way. Otherwise, are there downsides to enabling loading data from multiple sources?

Is your feature request related to a problem? Please describe.
Not related to a problem - more an enhancement.

Describe the solution you'd like
Are we able to expose the browser density value selected via the Flood UI so that it can be accessed as an environment variable within the script?

Additional context
This is in order to use this value as part of a calculation within the script.

Is your feature request related to a problem? Please describe.
Feature request. Use case: before the full load test runs in CI (like Jenkins) - validate that script is still functional - without spinning grid or using hours on flood.io

Describe the solution you'd like
return of element run test.ts to be not 0 if test failed. Right now regardless if test is passing or failing I am seeing "0" return code.

Describe alternatives you've considered
Some magic script to parse output?

Additional context
None

Going through steps in https://github.com/flood-io/element/blob/master/packages/cli/README.md#element-run
to run my first floodio-element test.

Installed NodeJS + all the tools ,installed element-cli,
created project files with "element init C:\Java\nodejs\projects\floodio\avatest"

And then it failed to run locally, please see the console log below.

Windows10-64, admin console:

c:\Java\nodejs\projects\floodio\avatest>node --version
v10.13.0

c:\Java\nodejs\projects\floodio\avatest>element --version
1.0.2

c:\Java\nodejs\projects\floodio\avatest>element run test.ts --verbose
+0s info: workRootPath: c:\Java\nodejs\projects\floodio\avatest\tmp\element-results\test\2018-11-13T12:12:00.753Z
+0s info: testDataPath: c:\Java\nodejs\projects\floodio\avatest

Error! An unexpected error occurred!
Error: EEXIST: file already exists, mkdir 'c:\Java\nodejs\projects\floodio\avatest\tmp\element-results\test'
at Object.mkdirSync (fs.js:750:3)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:71:13)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:77:24)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17) Error: EEXIST: file already exists, mkdir 'c:\Java\nodejs\projects\floodio\avatest\tmp\element-results\test'
at Object.mkdirSync (fs.js:750:3)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:71:13)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:77:24)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\ava\AppData\Roaming\npm\node_modules@flood\element-cli\node_modules\mkdirp\index.js:78:17)
this is a bug, please report it here https://github.com/flood-io/element/issues/new?template=bug_report.md

The idea behind this would be to declare a step which runs when any step fails, as a sort of catch-all. This could be used when the state of a page is not as expected, or authentication fails requiring starting at step 1 again.

step.recovery(async browser => {
  ...
})

// or with info

type RecoveryInfo = {
  failedStep: string
  reason: FailureReason
}

enum FailureReason {
  Timeout
  ElementNotFound
  PageCrashed
  // etc
}

step.recovery(info: RecoveryInfo, async browser => {
  ...
})

Unknowns:

• Need to think about how to redirect to the correct step afterward
• Should recovery be associated with a single step?

Is your feature request related to a problem? Please describe.

There is currently no way to upload files using file inputs.

Describe the solution you'd like

Expose an API method on the browser or element DSL for attaching a file to a file input, so we can support file uploads.

Additional context

This should be easy to support using elementHandle.uploadFile()

Currently if you run a script it will complain about not finding the type definitions, even if you declare @flood/chrome or @flood/element. This is probably an issue with resolving.

flood-challenge.ts:1:53 - error TS2307: Cannot find module '@flood/chrome'.

1 import { suite, By, Key, Until, TestSettings } from '@flood/chrome'
                                                      ~~~~~~~~~~~~~~~

I am running headless and can explicitly take a screenshot

await browser.takeScreenshot()

However, the test setting screenshotOnFailure: true, does not take a screenshot upon failure.

Is your feature request related to a problem? Please describe.
I want to check for an element to not match a specific text. That way I know it has changed after ie. button click. Writing an inverted regex pattern is not easy.

Describe the solution you'd like
Add Until.~DoesNotMatch as counterparts for Until.~Matches

• elementTextMatches(selectorOrLocator, regex) >> elementTextDoesNotMatch(selectorOrLocator, regex)
• titleMatches(title) >> titleDoesNotMatch(title)
• urlMatches(title) >> urlDoesNotMatch(title)

Describe alternatives you've considered
Inverted regex is something you'll need to look up, exposing a friendly alternative is nicer.

Additional context
I was able to figure out how to check for change with the following:

const regex = new RegExp("^(?!" + amountBefore + "$)");
await browser.wait(Until.elementTextMatches(amountLocator, regex));

Adding ~DoesNotMatch would allow this much simpler code:

const regex = new RegExp(amountBefore);
await browser.wait(Until.elementTextDoesNotMatch(amountLocator, regex));

• refactoring/fixes

  • time_to_first_interactive polyfill not working
  • uplift recast No parser and no filepath given, using 'babylon' the parser now but this will throw an error in the future. Please specify a parser or a filepath so one can be inferred.
  • fix this class of hardcoding https://github.com/flood-io/element/blob/feature/finish-cli-for-dev/packages/element/src/page/Condition.ts#L12
  • ensure specs run

• improvements

  • lift obscure/low-level errors to ease debugging

• separate grid & cli

• CI scripts

• move @flood/chrome into @flood/element

  • alias @flood/chrome to @flood/element for test scripts
  • refactor references to @flood/chrome
  • port over docs

• grid

  • move grid into a separate private repo using element
  • port over Dockerfile for grid tool container
  • ci scripts
  • grid / go grid support

• outstanding issues

  • --watch
  • @flood/chrome alias not working
  • running script from dir with node_modules picks the wrong @types/node
  • package installation smoke test
  • update to puppeteer 1.7
  • update to lerna 3.x
  • problem: think time is being used between actions
  • problem: re-add lockfile based concurrency
  • problem: screenshots
  • problem: assertions not working
  • move Timing & Tracing to grid (flood-element)
  • TestData
  • fix up signal handling
  • plan command
  • make --devtools/--no-headless leave the browser open
  • --slow-mo / --fast-forward
  • send detailed/documented errors via assertions

• dogfooding

  • incorrect error await browser.wait(Until.elementIsVisible(By.partialVisibleText("You're Done")))
  • --watch not triggered when using vs code terminal
  • Key.COMMAND / Key.CONTROL dev on mac, run on linux moved to #13
  • sendkeys chords CMD-A etc moved to #13
  • sendKeys doc
  • browser.click option types not coming through in vscode doc tooltip
  • some errors still escape - unhandled rejection need to leave this to error reports in the wild, hopefully with replication instructions
  • dedup compiler errors
  • update command mentions yarn update even when we used brew to install
  • update element.flood.io

Typical protocol error is opaque. We should make element work harder to extract useful info.

2018-07-23 13:26:13,655 - error: [01] [Iteration: 1] Error in Runner Loop: Error: Protocol error (Runtime.evaluate): Cannot find context with specified id undefined
Error: Protocol error (Runtime.evaluate): Cannot find context with specified id undefined

To Reproduce
Steps to reproduce the behavior:

1. cd packages/cli
2. NO_CHROME_SANDBOX=1 DEBUG=* yarn element run ../../examples/flood-challenge.ts

Expected behavior
Show better error info