Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Explain how FlowStages work and their rationale #558

Merged
merged 12 commits into from
Mar 8, 2024

Conversation

lukehesluke
Copy link
Contributor

Closes #557

FlowStages can then be queried after they've run in order to:

1. Check that the FlowStage was successful
- This is overridable per-FlowStage. For example, B's Flow Stage considers the run successful if the HTTP response has status 201
Copy link
Contributor

@civsiv civsiv Aug 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there default success checks? I can't remember if it does a default 200 check? If so something like:

Suggested change
- This is overridable per-FlowStage. For example, B's Flow Stage considers the run successful if the HTTP response has status 201
- This is overridable per-FlowStage. For example, B's Flow Stage considers the run successful if the HTTP response has status 201 as opposed to the default FlowStage behaviour that checks for status 200

The only reason I'm wondering whether there's default behaiour is due to the word "overridable". If there's no default behaviour, what's being overridden?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are not. So I'll change the word overridable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DONE

- This is overridable per-FlowStage. For example, B's Flow Stage considers the run successful if the HTTP response has status 201
- FlowStage method: `itSuccessChecks()`
2. Perform validation checks on the output
- This is overridable per-FlowStage. In all cases, this is a case of calling [Validator](https://github.com/openactive/data-model-validator) on the HTTP output.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here re overridable


Flows, consisting of Flow Stages, run the underlying API calls which are being tested, via Jest in the various Test Suite tests.

Jest tests involve a custom course of execution, in which setup occurs in `beforeEach`/`beforeAll` hooks, tests are run in `it` hooks, etc. Flow Stages are designed to work with this.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Jest tests involve a custom course of execution, in which setup occurs in `beforeEach`/`beforeAll` hooks, tests are run in `it` hooks, etc. Flow Stages are designed to work with this.
Jest tests involve a custom course of execution, in which setup occurs in `beforeEach`/`beforeAll` hooks and tests are run in `it` hooks, etc. Flow Stages are designed to work with this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i've done it slightly differently involving semicolons

@lukehesluke
Copy link
Contributor Author

@civsiv confirmed this as approved on another channel

@lukehesluke lukehesluke merged commit 880065f into master Mar 8, 2024
32 checks passed
@lukehesluke lukehesluke deleted the feature/flow-stage-docs branch March 8, 2024 11:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document how Test Suite FlowStages work, including the philosophy behind them
2 participants