Description

The order of creation in the basic demo/scenario has been: Application, Backing Service, and Service Binding Request - It should be possible to create these in any order and verify that binding works as a rebinding should be triggered automatically.

See:  https://github.com/redhat-developer/service-binding-operator/issues/69

Test scenario

The test works with 3 resources:

• Operator-managed Backing Service (PostgreSQL) custom resource [CR]
• Application Deployment(Config) [DC]
• Service Binding Request [SBR]

The steps, where the bold ones are to be permutated:

• As a starting point for tests (initial state/conditions):
  • Service Binding Operator is installed
  • Backing Service (database) Operator is installed

1. Create a namespace where all the resources would live.
2. Create a Backing Service (Database instance) CR
3. Create an Application DC
4. Set labels on the Application DC
5. Create a ServiceBindingRequest referencing the Backing Service and the Application DC
6. Verify that the Service Binding Operator bound the Application to the Backing Service by checking the environment variables set on the Application DC

Acceptance Criteria

The order of creation should support:

• Application, Backing Service, and Service Binding Request (covered in examples)
• Backing Service, Service Binding Request, and Application

The new tests should be automated and added to CI.