| 1 | # Flagpole JS
|
| 2 |
|
| 3 | Flagpole is a QA testing framework that is easy to learn, flexible, portable, and fast.
|
| 4 |
|
| 5 | - [Flagpole Developer Documentation](https://flocasts.github.io/flagpole/)
|
| 6 | - [Examples](https://github.com/flocasts/flagpole/tree/master/tests)
|
| 7 |
|
| 8 | ## Developer Style Guide
|
| 9 |
|
| 10 | - Class is ordered: public properties, private/protected properties, constructor, public methods, private/protected methods
|
| 11 | - Private/protected properties and methods are prefixed with \_
|
| 12 | - Camel-case all the things, except class names and enums
|
| 13 | - Interfaces are prefixed by i
|
| 14 | - Think about the developer experience of the person writing the tests first and foremost
|
| 15 | - Definitively type whenever possible
|
| 16 | - Favor readability over cleverness or brevity
|
| 17 | - Document and comment liberally
|
| 18 | - Don't try to do everything, but do the common QA functions really well
|
| 19 | - As much as possible, create a common experience across different classes of scenarios
|
| 20 | - Keep the framework as light as possible, which might mean auto-discovery and dynamically loading optional libraries
|
| 21 | - It should be obvious, it should mislead of confuse or cause additional cognitive load
|
| 22 | - Do what you say, say what you do. No side effects.
|
| 23 | - Try to start methods with verbs unless it's just really short, sweet, and obvious not to
|
| 24 | - Start properties or methods that return booleans with "is" or "has" or "can" or something similar that reads what it is
|
| 25 | - Start methods that convert an object to a different type with "to" like "toArray"
|
| 26 | - 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.
|