Story (Required)

As a developer maintaining test coverage trying to understand and validate system behavior, I want "Run" unit tests broken down to target individual child methods (startPR for this ticket) instead of a single large test method.

Background (Required)

The current test suite contains a large monolithic test method that covers multiple child methods within a single test.
This approach makes it difficult to identify the root cause of failures, especially when changes are made to individual components.
Additionally, it increases the cognitive load for developers trying to understand the system and leads to brittle tests that are hard to maintain.

Breaking these tests down to align with their corresponding child methods will improve clarity, reduce test interdependencies, and align with best practices for unit testing.

Out of scope

• Refactoring of the actual child methods’ logic

• Integration or end-to-end tests for these methods

• Changes to unrelated test files or test utilities

Approach (Required)

• Locate the large test method TestRun in pipelineascode_test.go, which currently covers multiple child methods.

• Isolate the logic related to the startPR child method.

• Create a dedicated set of unit tests specifically for startPR, ensuring:

• • Tests are placed in the same pipelineascode_test.go file

• • Proper mocking/stubbing is used to isolate startPR's behavior

• • Tests handle both expected behavior and edge cases

• Ensure test method naming follows standard conventions

• Maintain or improve overall test coverage

• Validate the changes locally and ensure they pass in CI

Dependencies

This story is part of the larger effort to improve test granularity in pipelineascode_test.go (https://issues.redhat.com/browse/SRVKP-7883)

Acceptance Criteria (Mandatory)

All unit tests related to `startPR` are extracted from the `TestRun` method into separate, dedicated test functions

• Tests for `startPR` cover:
    - Standard execution flow
    - Error handling (e.g. invalid inputs, expected failures)
    - Boundary/edge cases, if applicable
• Test names follow the pattern `TestStartPR_*` and clearly describe the scenario under test
• No logic from unrelated child methods is included in the new tests
• The original `TestRun` method is updated if needed to remove redundant coverage of `startPR`
• All new tests pass locally and in the CI pipeline
• Overall test coverage remains the same or improves

  INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met