Test generation is working now in a very prototype style of way.

ToDos:

• Generated file still has the __tmpl__ extenstion
• 1-2 hardcoded assumptions -> aggregate it is all about & aggregate identifier
• Stop the onEvent/onCommand ... hooks when the feature/context mode is set to test
• Fix formatting of the payloads (the ' gets decoded to ' currently...)
• Exclude generated files via .gitignore
• Generate gherkin feature file from prooph feature metadata
• General cleanup
• template serviceNames.fileName refers to "Testboard" instead of "fleetmanagement"

• test-scenarios fix for Windows
• rename to mode: test-scenario

Some notes from our call:

• aggregates: see https://github.com/proophboard/cody-engine/blob/main/packages/cody/src/lib/hooks/on-event.ts#L27 (getOriginalEvent helper)
• stop hooks: in the handlers, check if inside a test scenario
• gitignore: only relevant in contribution mode!
• gherkin feature file: auto-generate like the steps TS file, discard/remove metadata in test feature on the board

I started refactoring the step definitions. Step definitions should be per aggregate and not per feature. This will make steps "reusable" throughout different scenarios regarding the same aggregate.

For example to test if a car was completed or not after an update we would have two test scenarios that are identical until the then step and just the input data per scenario is different. To achieve this i want to check the decoraters of the aggregate Step definition and see if a new definition is required or if it already exists.

Payloads will be written per Feature into the new folder features/payloads/FEATURENAMEFeature.json. They are read dynamically in the setup function of the Step Definition to keep them reusable.

Example to make it more clear:

Feature: Update Car Without Production Year
  Scenario: Update Car Without Production Year
    Given Incomplete Car was added
    When Car is updated without production year
    Then car should be updated

To test that an update with production year would have a different outcome we still want the same starting point.

Feature: Update Car With Production Year
  Scenario: Update Car With Production Year
    Given Incomplete Car was added
    When Car is updated with production year
    Then car should be added to fleet

This will be possible once the refactoring is done. Ideally both scenarios are actually in the Update Car Feature, so maybe i will have a look if that is possible as well.