Hi,

Your frustrations are entirely valid, especially because there is a gap in detailed documentation for using the BDD Framework specifically with ODC (OutSystems Developer Cloud). The framework is better documented for traditional OutSystems environments, but adapting it to ODC clearly requires some additional effort.

I'll try to address your critical questions based on the information available:

1. Installation and Configuration of BDDFrameworkTestRunLib

According to the OutSystems documentation, the BDDFrameworkTestRunLib should be included in the testing app, i.e., the app where your tests are defined, rather than the app being tested. This library provides the API endpoints required for triggering and managing tests.

To configure it:

• Install the BDDFramework component from the Forge in your ODC environment, as outlined in Component Testing with BDDFramework Tools.
• Ensure the BDDFrameworkTestRunLib is made public in your testing app so that its services can be invoked.

For the API placeholders:

• <serverurl> should point to your ODC environment URL. Example: https://your-environment.outsystemscloud.com.
• {TestESpace} is the module name of your test suite (e.g., MyApp_Tests).
• {TestSuiteScreen} is the name of the Test Suite screen you've constructed in the test module (e.g., MyFirst_TestSuite).

2. Configuring GWT (Given-When-Then) Statements Using BDDSteps in a Sequence

The BDD Framework uses Gherkin-like syntax for tests, implemented through BDDScenario, BDDStep, and other web blocks on your Test Suite screen. Here’s the general approach:

1. For each acceptance criterion, create a BDDScenario web block to represent the scenario.
2. For each step of the criterion, add a BDDStep web block inside the BDDScenario.
3. In each BDDStep, implement the logic (in Actions) necessary to perform and verify the step.

To ensure sequential execution:

• Link the steps logically in the action flows tied to each BDDStep. Usually, once a BDDStep completes execution, control passes to the next step in the scenario.

Referencing Component Testing may help you understand the block organization and how to use reusable patterns effectively.

3. Configurations for Triggering Tests

Testing triggers can be implemented in three ways:

• Manually Triggered: Add a button or endpoint in your testing app that calls the APIs provided by BDDFrameworkTestRunLib to execute specific test suites.
• On App Publish: Use LifeTime's API to hook into the application deployment process and trigger the tests automatically as part of a CI/CD pipeline. However, detailed steps for this on ODC are not yet well-documented.
• On Schedule: Use the built-in Timers functionality in OutSystems to schedule recurring test runs. Create a timer in the testing app, and within it, invoke the BDD APIs to execute desired test cases automatically.

I would strongly recommend reading Component Testing with BDDFramework Tools for guidance specific to ODC environments, even though the documentation may not yet be as comprehensive as needed for advanced setups.

If you’ve exhausted these steps and are still encountering issues, an alternative approach might involve leveraging a custom-built framework or extending the current BDD tools to better align with your ODC requirements. The community or OutSystems Support might be able to assist with those specialized adaptations.

Hopefully, this information helps clarify your next steps for implementing BDD with ODC. Let me know if you need further assistance with any specific part of the setup.