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.
|