Flagpole JS

"Let me run it up the flagpole first"

Running something up the flagpole means you check on it first to see if it's good before going forward. And that's exactly what this framework is about, so we like the analogy.

"Swiss army knife of end-to-end QA testing"

Flagpole is a QA testing framework that is easy to learn, flexible, portable, and fast. How can Flagpole be do so many things well? We don't try to build everything from scratch, Flagpole leverages the best tools in the business and puts them under one roof in a consistent interface.

It supports a number of different types of testing:

Full browser testing with Puppeteer
Super-fast HTML DOM testing with Cheerio (jQuery for Node)
REST API/JSON End Points with Schema Snapshots and validation of JSON Schema and JSON Type Definition (JTD) schemas
Lightweight image tester that can verify the dimensions, mime and file size without downloading the whole thing
Basic validation for other resources like Stylesheets, JavaScript
Visual comparisons of a screenshot against a control image
Generic XML
RSS or Atom feeds

Flagpole is designed to be simple so that the most junior engineer or QA analyst can pick it up within hours. But it is so powerful it can take years to master and satisfy the most senior engineer.

Flagpole is designed for portability, so that you can run it locally within your repository from a githook, in the cloud when something is deployed, as a scheduled job, or manually any time you want.

Flagpole has a rich CLI that can be used to list tests, run tests, create new suites or scenarios, etc.

Documentation

Flagpole Docs

Example Test Scenarios

Flagpole Users

FloSports

Echelon Fitness

Want to contribute?

Sure! Please contribute your pull request.

Developer Style Guide

Class is ordered: public properties, private/protected properties, constructor, public methods, private/protected methods
Private/protected properties and methods are prefixed with _
Camel-case all the things, except class names and enums
Interfaces are prefixed by i
Think about the developer experience of the person writing the tests first and foremost
Definitively type whenever possible
Favor readability over cleverness or brevity
Document and comment liberally
Don't try to do everything, but do the common QA functions really well
As much as possible, create a common experience across different classes of scenarios
Keep the framework as light as possible, which might mean auto-discovery and dynamically loading optional libraries
It should be obvious. It should not mislead, confuse, or cause additional cognitive load
Do what you say, say what you do. No side effects.
Try to start methods with verbs unless it's just really short, sweet, and obvious not to
Start properties or methods that return booleans with "is" or "has" or "can" or something similar that reads what it is
Start methods that convert an object to a different type with "to" like "toArray"
Some things are designed to be chained, such as setting up a Suite or Scenario, so allow this to be chained by returning themselves, but don't chain just for the sake of chaining. Chain of readability and convenience of DX only.

.

Most popular functions for flagpole

To help you get started, we’ve selected a few flagpole examples, based on popular ways it is used in public projects.

flagpole.Flagpole.Suite