Improve BDD with new testing command

composer.json

@@ -50,7 +50,12 @@
         "sort-packages": true
     },
     "scripts": {
-        "behat": "behat --config tests/Behat/behat.yml --format progress",
+        "bdt": [
+            "@behat --format=progress --suite=redmine_50103",
+            "@behat --format=progress --suite=redmine_50009",
+            "@behat --format=progress --suite=redmine_40210"
+        ],
+        "behat": "behat --config tests/Behat/behat.yml",
         "codestyle": "php-cs-fixer fix",
         "coverage": "phpunit --coverage-html=\".phpunit.cache/code-coverage\"",
         "phpstan": "phpstan analyze --memory-limit 512M --configuration .phpstan.neon",

tests/Behat/README.md

@@ -10,27 +10,35 @@ Pull the Redmine docker images and start them by running:
 docker compose up -d
 ```
 
-Now you can run the tests:
+Now you can run all behaviour-driven tests grouped by Redmine version using the `bdt` command:
 
 ```bash
 # all tests
-docker compose exec php composer behat
-# only a specific redmine version
+docker compose exec php composer bdt
+```
+
+If you need more control about the behat tests or want to change the output format,
+you can use the `behat` command directly:
+
+```bash
+# test only a specific redmine version
 docker compose exec php composer behat -- --suite=redmine_50103
-# only specific endpoints
+# test only specific endpoints
 docker compose exec php composer behat -- --tags=issue,group
-# only specific endpoints on a specific redmine version
+# test only specific endpoints on a specific redmine version
 docker compose exec php composer behat -- --suite=redmine_50103 --tags=issue,group
+# test only a specific redmine version and format the output as `progress` (default is `pretty`)
+docker compose exec php composer behat -- --suite=redmine_50103 --format=progress
 ```
 
-## Redmine specific features
+## Redmine version specific features
 
-Some Redmine features are specific for a Redmine version. There are two ways to handle this situations.
+Some Redmine features are specific for a Redmine version. Theses situations are handled in different ways.
 
 ### Modified Rest-API Responses
 
 It is possible that a new Redmine version returns new or changed elements in a response.
-This can be handled on the `step` layer:
+This can be handled on the `step` layer (note the missing `homepage` property in `< 5.1.0`):
 
 ```
         And the returned data "projects.0" property has only the following properties with Redmine version ">= 5.1.0"
@@ -40,29 +48,20 @@ This can be handled on the `step` layer:
             identifier
             description
             homepage
-            status
-            is_public
-            inherit_members
-            created_on
-            updated_on
             """
         But the returned data "projects.0" property has only the following properties with Redmine version "< 5.1.0"
             """
             id
             name
             identifier
             description
-            status
-            is_public
-            inherit_members
-            created_on
-            updated_on
             """
 ```
 
 ### New Rest-API Endpoints
 
-A new Redmine version could be introduce new REST-API endpoints that are missing in the older version.
+A new Redmine version could introduce new REST-API endpoints.
+Tests for this endpoint should not be run on older Redmine versions.
 This can be handled on the `scenario` or `feature` layer.
 
 1. Tag features or scenarios e.g. with `@since50000`.
@@ -98,7 +97,8 @@ default:
 
 ### Removed Rest-API Endpoints
 
-A new Redmine version could remove REST-API endpoints that are missing in the newer versions.
+A new Redmine version could remove REST-API endpoints.
+Tests for this endpoint should not be run on newer Redmine versions.
 This can be handled on the `scenario` or `feature` layer.
 
 1. Tag features or scenarios e.g. with `@until60000`.