Install Flood Element CLI to run TypeScript which (like Selenium) emulates manual actions in Google Chrome browsers
This is a hands-on step-by-step introduction to automate installation of the flood.io Element CLI which validates TypeScript locally. After validation, the scripts are used on flood.io in the cloud to performance test public websites.
NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.
This is a component illustrated as the upper-right corner of the video and flowchart at https://wilsonmar.github.io/flood-the-internet, reiterated here:
PROTIPs here provide additional commentary based on experience and foresight not available elsewhere.
Setup Flood Element CLI locally
To run a Flood Element script against a sample app on the web, use Flood’s
element executable program.
To make that easy for you, a shell script was developed and made available in a GitHub.com repository.
PROTIP: Security conscious people would be wise to first copy the file, vet it with Security experts, then save the certified file within a corporate-sponsored vault, perhaps using Nexus or Artifactory.
Use an internet browser (Google Chrome) to view the raws script at my public GitHub repository:
(The script is based in part on the “End to End Example” shell script at Flood.io README)
Our script has the following steps:
- Collect parameters controlling this run:
- Context: Starting time stamp, OS versions, command attributes:
- Shell utility functions:
- Delete local repository if it’s there (for idempotency):
- Pre-requisites installation (jq to handle JSON)
- install cli
- Clone script from GitHub
- Run the script
- Clean up
Notice that puppeteer is installed. The Node package..
The script has are several run control parameters (feature flags) in the script.
If you are installing on a new Linux instance in the cloud, first instantiate the machine image.
To run the script with default settings on your Mac or Linux laptop,triple-click this URL and paste it in your Terminal:
sh -c "$(curl -fsSL https://raw.githubusercontent.com/wilsonmar/DevSecOps/master/flood-io/flood-local-setup.sh)"
Below examines what the script does, which is summarized in the flood.io documentation page at: https://element.flood.io/docs/1.0/install, but with pre-edits and verifications.
Get package manager for your operating system.
On a Mac, install Homebrew.
On Ubuntu, install apt-get.
Many Linux distributions now come with a package manager.
Use the package manager to install utilities. On a Mac:
brew install flood-io/taps/element
Skip to Verify install.
NOTE: There is also a flood-io/taps/aqueduct which enables Flood Element scripts to run behind the corporate firewall within a private cloud.
Install NodeJs NPM globally if it’s not already installed. Do this to avoid messages during element-cli installation such as:
npm WARN deprecated firstname.lastname@example.org: 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@example.com: cross-spawn no longer requires a build toolchain, use it instead
Most people use NPM to install the element CLI program globablly:
npm install -g @flood/element-cli
PROTIP: The response leverages Google Chromium Pupeteer that also powers Google Chrome browser Developer Tools. This means Firefox and other browsers are not supported.
> firstname.lastname@example.org install /Users/wilsonmar/.nvm/versions/node/v9.11.1/lib/node_modules/@flood/element-cli/node_modules/puppeteer Downloading Chromium r575458 - 80.4 Mb [====================] 100% 0.0s Chromium downloaded to /Users/wilsonmar/.nvm/versions/node/v9.11.1/lib/node_modules/@flood/element-cli/node_modules/puppeteer/.local-chromium/mac-575458 + @email@example.com added 626 packages from 436 contributors in 180.277s
Alternately, if you want the very latest beta varsion of Flood’s Element CLI:
yarn global upgrade @flood/element-cli@beta
At the time of writing, the beta version is needed to mouse by x,y coordinates.
At time of writing:
List the major sub-commands:
element init [dir] [options] Init a test script and a minimal environment to get you started with Flood Element element generate <file> [options] Generate a basic test script from a template element plan <file> [options] Output the test script plan without executing it. element run <file> [options] Run a test script locally
Clone sample Flood Element script
Create a folder just for this purpose.
Install Git if one was not already installed.
Clone (obtain) Element scripts written for a sample app (instead of running
element initto be prompted) to generate a new minimal script per the docs):
There are several sample apps with Element scripts available in Flood’s load-testing-playground repo:
A Woocommerce website with these Element scripts as described in Flood’s on-line documentation
A Magento website with these Element scripts as described in Flood’s on-line documentation
A video streaming website (YouTube) with these Element scripts as described in Flood’s on-line documentation
JPetstore used as a sample app because it was written in Java. But it’s front-end technology is now considered obsolete.
EasyTravel from Dynatrace has both Java and .NET components.
“microtrader” websockets application maintained as the sample app for a video tutorial on Pluralsight.
For the purposes of this tutorial:
git clone https://github.com/daeep/Flood_Element && cd Flood_Element
Run sample Flood Element script
For a reminder of sub-commands to run stuff:
element run –help
element run <file> [options] Run a test script locally Browser: --chrome Specify which version of Google Chrome to use. Default: use the puppeteer bundled version. stable: --no-headless Run in non-headless mode so that you can see what the browser is doing as it runs the test --devtools Run in non-headless mode and also open devtools --no-sandbox Disable the chrome sandbox - advanced option, mostly necessary on linux Running the test script: --watch Watch
and rerun the test when it changes. --fast-forward, --ff Run the script in fast-forward: override the actionDelay and stepDelay settings to 1 second in the test script. Specify a number to set a different delay. --slow-mo Run the script in slow-motion: Increase the actionDelay and stepDelay settings in the test script to 10 seconds. Specify a number to set a different delay. --step-delay Override stepDelay test script setting [number] --action-delay Override actionDelay test script setting [number] --loop-count Override the loopCount setting in the test script. This is normally overridden to 1 when running via the cli. [number] [default: 1] --strict Compile the script in strict mode. This can be helpful in diagnosing problems. Paths: --work-root Specify a custom work root. (Default: a directory named after your test script, and at the same location) --test-data-root Specify a custom path to find test data files. (Default: the same directory as the test script) Positionals: file the test script to run [required] Options: --version Show version number [boolean] --help Show help [boolean] --verbose Verbose mode</pre>
Run a sample script against one of the tests listed in http://wilsonmar.github.io/flood-the-internet/#challenges-on-the-internet:
Two different approaches are available:
npxto invoke NPM binary
element-cliwithout a global install*
npx @flood/element-cli run "$SCRIPT_PATH" --no-headless
elementcommand if element-cli was installed globally:
element run “$SCRIPT_PATH” --no-headless
--no-headlessopens a browser instance so you can see it playing back.
If see this message, click “Allow”:
The response begins with:
+0s info: workRootPath: /Users/wilsonmar/projects/flood-io/Flood_Element/tmp/element-results/04-Challenging_DOM/2019-06-26T044133.811Z
NOTE: The above message specifies where results will be stored locally.
The response ends with:
+0s info: testDataPath: /Users/wilsonmar/projects/flood-io/Flood_Element +7s info: ---> wait() +7s info: ---> Step 'Test: 01 - Homepage' finished +10s info: +10s info: ===> Step 'Test: 02 - Challenging DOM' +10s info: ---> wait() +10s info: ---> Step 'Test: 02 - Challenging DOM' finished +13s info: +13s info: ===> Step 'Test: 03 - Challenging DOM - Click Button' +13s info: ---> wait() +13s info: ---> Step 'Test: 03 - Challenging DOM - Click Button' finished +16s info: +16s info: ===> Step 'Test: 04 - Challenging DOM - Click Button Alert' +17s info: ---> wait() +17s info: ---> Step 'Test: 04 - Challenging DOM - Click Button Alert' finished +20s info: +20s info: ===> Step 'Test: 05 - Challenging DOM - Click Button Success' +20s info: ---> wait() +20s info: ---> Step 'Test: 05 - Challenging DOM - Click Button Success' finished +23s info: Iteration completed in 20018ms (walltime) +23s info: Test completed after 1 iterations process exited
TODO: Capture the response. Have a program scan through it to record the number of seconds (such as “20018ms (walltime)”) along with date and script name, etc. as metadata about runs for historical comparisons.
Look into the path using the tree command, to see these folders:
flood |-- files |-- network |-- objects |-- results |-- screenshots `-- traces