niko
8f1bf7e347
Add dispatch-workflow.sh script that dispatches a Gitea workflow in another repository and polls synchronously for completion. Refactor mock-api.sh to use Python3 HTTP server with sequence support, enabling stateful poll-response simulation in tests. --------- Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #4
93 lines
4.3 KiB
Gherkin
93 lines
4.3 KiB
Gherkin
Feature: Test execution
|
|
As a test engineer
|
|
I want integration and end-to-end tests to run automatically after deployment
|
|
So that I can verify the deployed version works correctly
|
|
|
|
Background:
|
|
Given a deployment has completed in the target environment
|
|
And the test project repository exists with test definitions
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Ticket 0002: dispatch-workflow.sh — Dispatching and polling workflows
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@ticket-0002 @mock @real
|
|
Scenario: Dispatch a test workflow and wait for its completion
|
|
When a test workflow is dispatched to a test project
|
|
Then the pipeline waits until the test workflow finishes
|
|
And the pipeline continues only after receiving a success result
|
|
|
|
@ticket-0002 @mock @real
|
|
Scenario: Dispatch fails when the dispatched test workflow fails
|
|
When a test workflow is dispatched and the tests fail
|
|
Then the calling pipeline reports failure
|
|
|
|
@ticket-0002 @mock
|
|
Scenario: Dispatch times out when the test workflow takes too long
|
|
When a test workflow is dispatched but does not finish within the allowed time
|
|
Then the calling pipeline reports a timeout error
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Ticket 0011: check-version.sh — Version polling with Fibonacci backoff
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@ticket-0011 @mock @wip @real
|
|
Scenario: Target version is eventually found after a few retries
|
|
When the deployed version in the environment does not match the expected version initially
|
|
And the version check is retried with increasing wait times
|
|
Then the version eventually matches and the test flow proceeds
|
|
|
|
@ticket-0011 @mock @wip
|
|
Scenario: Target version is never found within the maximum retries
|
|
When the deployed version keeps returning a different version than expected
|
|
And the maximum number of retries is reached
|
|
Then the version check fails with a version mismatch error
|
|
|
|
@ticket-0011 @mock @wip
|
|
Scenario: Version check fails when the version endpoint cannot be reached
|
|
When the version API endpoint is not responding
|
|
Then the version check fails with an error
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Ticket 0008: test.yml — Test flow execution and cross-repo reporting
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@ticket-0008 @mock @wip @real
|
|
Scenario: Test flow verifies the deployed version before running tests
|
|
When a test flow is triggered
|
|
Then the version of the running container is checked against the expected version
|
|
And tests proceed only after the version matches
|
|
|
|
@ticket-0008 @mock @wip @real
|
|
Scenario: Test flow executes tests and publishes reports
|
|
When tests are executed as part of the test flow
|
|
Then the test reports are published to the report storage
|
|
And the reports are accessible through the browse interface
|
|
|
|
@ticket-0008 @mock @wip @real
|
|
Scenario: Test flow reports results to the test project commit
|
|
When tests complete
|
|
Then the test project commit shows a test status with a link to the report
|
|
|
|
@ticket-0008 @mock @wip @real
|
|
Scenario: Test flow reports results back to the source commit
|
|
When tests complete for a source commit
|
|
Then the source commit shows which tests were run and a link to the results
|
|
|
|
@ticket-0008 @mock @wip @real
|
|
Scenario: Test flow reports the tested version on the deployment commit
|
|
When tests complete
|
|
Then the deployment commit shows which version was tested and a link to the test results
|
|
|
|
@ticket-0008 @mock @wip @real
|
|
Scenario: Developer traces the full chain from source commit through deployment to test results
|
|
When a developer views the source commit
|
|
Then they can follow the deployment status to the deployment commit
|
|
And from the deployment commit they can follow the test status to the test results
|
|
And from the test results they can navigate back to the source commit
|
|
|
|
@ticket-0008 @mock @wip @real
|
|
Scenario: Developer sees which container version was tested on the test project commit
|
|
When a developer views the test project commit
|
|
Then the commit shows the tested container version and the source commit it originated from
|