diff options
| -rw-r--r-- | fable-arch.md | 77 |
1 files changed, 45 insertions, 32 deletions
diff --git a/fable-arch.md b/fable-arch.md index 532ab3a..6c63b7f 100644 --- a/fable-arch.md +++ b/fable-arch.md @@ -104,38 +104,51 @@ Fable](#acceptance). Each requirement here is given a unique mnemnoic id for easier reference in discussions. -* **UnderstadableTests:** Acceptance tests should be possible to express in - a way that's easily understood by non-programmers. - -* **EasyToWriteDocs:** The markup language for writing documentation - should be easy to write. - -* **AidsComprehension:** The formatted human-readable documentation - should use good layout and typography to enhance comprension. - -* **CodeSeparately:** The code to implement the acceptance tests - should not be embedded in the documentation source, but be in - separate files. This makes it easier to edit without specialised - tooling. - -* **AnyProgammingLanguage:** The developers implementing the - acceptance tests should be free to use a language they're familiar - and comfortable with. Fable should not require them to use a - specific language. - -* **FastTestExecution:** Executing the acceptance tests should be - fast. - -* **NoDeployment:** The acceptance test tooling should assume the - system under test is already deployed and available. Deploying is - too big of a problem space to bring into the scope of acceptance - testing, and there are already good tools for deployment. - -* **MachineParseableResults:** The tests should produce a machine - parseable result that can be archived, post-processed, and analyzed - in ways that are of interest to the project using Fable. For - example, to see trends in how long tests take, how often tests fail, - to find regressions, and to find tests that don't provide value. +**UnderstadableTests** + +: Acceptance tests should be possible to express in a way that's + easily understood by non-programmers. + +**EasyToWriteDocs** + +: The markup language for writing documentation should be easy to + write. + +**AidsComprehension** + +: The formatted human-readable documentation should use good layout + and typography to enhance comprension. + +**CodeSeparately** + +: The code to implement the acceptance tests should not be embedded in + the documentation source, but be in separate files. This makes it + easier to edit without specialised tooling. + +**AnyProgammingLanguage** + +: The developers implementing the acceptance tests should be free to + use a language they're familiar and comfortable with. Fable should + not require them to use a specific language. + +**FastTestExecution** + +: Executing the acceptance tests should be fast. + +**NoDeployment** + +: The acceptance test tooling should assume the system under test is + already deployed and available. Deploying is too big of a problem + space to bring into the scope of acceptance testing, and there are + already good tools for deployment. + +**MachineParseableResults** + +: The tests should produce a machine parseable result that can be + archived, post-processed, and analyzed in ways that are of interest + to the project using Fable. For example, to see trends in how long + tests take, how often tests fail, to find regressions, and to find + tests that don't provide value. # Fable architecture |