Menu

Tree [30070c] master /
 History

HTTPS access


File Date Author Commit
 features 2024-05-04 Henk van den Akker Henk van den Akker [30070c] Feature 45: Compatibility check GTD mind map
 .gitignore 2024-05-04 Henk van den Akker Henk van den Akker [1bb2ff] Feature 45: Compatibility check GTD mind map
 README.md 2024-05-02 Henk van den Akker Henk van den Akker [e87374] Feature 45: Compatibility check GTD mind map

Read Me

GTD Sync feature repository

This repository aims to group all GTD Sync features systematically instead of scatter them over many tickets. It is separate from the GTD Sync code repository so that we can prepare current release while refining future features in parallel. Another aim is to develop an automated regression test based on the scenario's in the features.

Standards and style for gherkin scenarios

Guidelines for making new and refactoring existing scenarios

  1. In case the scenario concerns the need of the user, write it in the 'I' form
  2. In case the scenario deals with backward incompatibility, write it in the 'you' form
  3. The Then statements are in the 'should' form
  4. The scenario should describe GTD Sync behaviour and not (detailed) actions
  5. Indentation is always 2 spaces
  6. Descriptions start with '|', that is preformatted text in Robot Framework
  7. Feature description consists of user story, short explanation and rules
  8. Outline parameters without quotes unless you would quote it anyway
  9. Limit a feature to a maximum of 10 scenarios
  10. Make scenarios for all OSs (Windows, Linux and macOS) or for a single OS.
  11. In the latter case tag it with the OS, so it can be excluded when running tests for the other OSs.
  12. Do not use OS as an Examples variable
  13. Use per new of changed scenario a tag for development stage and remove after release

Tags per development stage

The following tags should be added to scenarios during development

Tag To what When
new_refined New scenario Before it is built
new_built New scenario After it is built
changed_refined Changed scenario Before it is built
changed_built Changed scenario After it is built
changed_original Original to changed scenario After changed scenario is built

In addition, add tag for release and ticket. In this way a record can be kept of what is built and what still has to be done.

When testing a minor or major release, exclude the tags new_refined, changed_refined and changed_original.

When testing a patch release, exclude the tags new_refined, new_built changed_refined and changed_built.

After a scenario is released these tags and the original to a changed scenario can be removed.

Translation to test tooling

We are going to use Robot Framework to automate the test of the features. Gherkin2robotframework is going to be used to convert feature files to high level Robot Framework tests. This combination of tools does not support all gherkin keywords, hence the following overview. We should avoid keywords that are not supported.

Keyword Supported Use Remark
Feature Yes Yes Description goes to documentation suite
Rule No No New (Gherkin 6) and not yet widely supported
Scenario Yes Yes Description goes to documentation test case
Example No No Equivalent to Scenario
Given Yes Yes
When Yes Yes
Then Yes Yes
And Yes Yes
But Yes Yes
* No No
Background Yes Yes Not for scenario outlines
Scenario Outline Yes Yes Description goes to documentation RF template
Examples Yes Yes
""" (Doc Strings) Yes Yes
| (Data Tables) Yes Yes
@ (Tags) Yes Yes Officially only above Feature
# (Comments) No No