diff --git a/functional_tests/README.md b/functional_tests/README.md new file mode 100644 index 0000000..f168669 --- /dev/null +++ b/functional_tests/README.md @@ -0,0 +1,18 @@ +# Roost Generated Functional Test + +**Execution Date:** 4/30/2026, 1:32:47 PM + +**Test Unique Identifier:** "ZBIO-7758" + +**Input(s):** + 1. JIRA ID: ZBIO-7758 + +**Test Output Folder:** + 1. [ZBIO-7758.json](ZBIO-7758/ZBIO-7758.json) + 2. [ZBIO-7758.feature](ZBIO-7758/ZBIO-7758.feature) + 3. [ZBIO-7758.csv](ZBIO-7758/ZBIO-7758.csv) + 4. [ZBIO-7758.xlsx](ZBIO-7758/ZBIO-7758.xlsx) + 5. [ZBIO-7758.docx](ZBIO-7758/ZBIO-7758.docx) + +--- + diff --git a/functional_tests/ZBIO-7758/.roost/roost_metadata.json b/functional_tests/ZBIO-7758/.roost/roost_metadata.json new file mode 100644 index 0000000..636cee0 --- /dev/null +++ b/functional_tests/ZBIO-7758/.roost/roost_metadata.json @@ -0,0 +1,19 @@ +{ + "project": { + "name": "ZBIO-7758", + "created_at": "2026-04-30T08:02:47.312Z", + "updated_at": "2026-04-30T08:02:47.312Z" + }, + "files": { + "input_files": [ + { + "fileName": "ZBIO-7758.txt", + "fileURI": "/var/tmp/Roost/RoostGPT/TestFUNct01/1777535727/functional_tests/ZBIO-7758/ZBIO-7758.txt", + "fileSha": "720bc7cd24" + } + ] + }, + "api_files": { + "input_files": [] + } +} \ No newline at end of file diff --git a/functional_tests/ZBIO-7758/ZBIO-7758.csv b/functional_tests/ZBIO-7758/ZBIO-7758.csv new file mode 100644 index 0000000..1b64541 --- /dev/null +++ b/functional_tests/ZBIO-7758/ZBIO-7758.csv @@ -0,0 +1,26 @@ +Successful fetch of an existing JIRA issue +Fetch with non-existent or forbidden issue returns appropriate HTTP error +Fetch with invalid authentication returns 401 +Fetch with missing JIRA_TOKEN environment variable fails with configuration error +Concurrent fetch of the same existing JIRA ID should not produce false 404s +Fetch with network timeout triggers timeout error and retry logic +Fetch with malformed JIRA_BASE_URL results in connection error +Credential expiry mid-suite is handled and suite continues +Successful fetch log contains required fields for audit trail +Fetches from different stacks use correct JIRA_BASE_URL +Fetch with transient HTTP 500 triggers retry and eventual success +Fetch using incorrect JIRA API version returns appropriate error +Fetch with invalid JIRA ID formats fails gracefully +Fetch with HTTP 429 rate limiting response is handled +Systematic test of credential validity vs JIRA ID existence +Error log format consistency for different error types +Sequential fetches with credential rotation between requests +HTTP redirect from JIRA API is followed correctly +HTTP 200 with error body in response is treated as failure +Fetch a newly created JIRA issue immediately to test eventual consistency +Error log contains mandatory audit fields +Fetch receives HTTP 204 No Content and logs error +HTTP 200 response missing mandatory fields is treated as failure +SSL certificate validation failure logs connection error +Sequential fetches of different JIRA IDs are independent +Extremely short timeout (1ms) causes immediate timeout error \ No newline at end of file diff --git a/functional_tests/ZBIO-7758/ZBIO-7758.docx b/functional_tests/ZBIO-7758/ZBIO-7758.docx new file mode 100644 index 0000000..bd993ca Binary files /dev/null and b/functional_tests/ZBIO-7758/ZBIO-7758.docx differ diff --git a/functional_tests/ZBIO-7758/ZBIO-7758.feature b/functional_tests/ZBIO-7758/ZBIO-7758.feature new file mode 100644 index 0000000..9275b82 --- /dev/null +++ b/functional_tests/ZBIO-7758/ZBIO-7758.feature @@ -0,0 +1,287 @@ +Feature: JIRA Issue Fetch API Tests + As a system that fetches JIRA issue details + I want to verify the fetch functionality under various conditions + So that I can ensure robust error handling and reliable operation + + # Background: Common valid setup (will be overridden in specific scenarios) + Background: + Given the API base URL is set from environment variable "JIRA_BASE_URL" + And the JIRA user is set from environment variable "JIRA_USER" + And the JIRA token is set from environment variable "JIRA_TOKEN" + And the content type is "application/json" + And the default timeout is 5000 milliseconds + + # Test case: TC-JIRA-001 - Successful fetch of existing issue + @TC-JIRA-001 @positive + Scenario: Successful fetch of an existing JIRA issue + Given a valid JIRA issue ID "ZBIO-7718" exists in the system + When I send a GET request to "/issue/ZBIO-7718" + Then the response status should be 200 + And the response body should contain fields: "id", "key", "summary", "status" + And the log should contain an INFO entry with "JIRA-ID: ZBIO-7718" and "HTTP 200" + + # Test case: TC-JIRA-002 - Non-existent ID returns 404 with exact error message + # Also covers scenario for any non-existent ID with valid creds + # Combined with TC-JIRA-019 (forbidden due to permissions) + @TC-JIRA-002 @TC-JIRA-019 @error-handling + Scenario Outline: Fetch with non-existent or forbidden issue returns appropriate HTTP error + Given a valid JIRA issue ID "" in the system + And the credentials have + When I send a GET request to "/issue/" + Then the response status should be + And the error log should contain "Failed to get details for JIRA-ID: with error: AxiosError: Request failed with status code " + Examples: + | issue_id | condition | credential_permission | status | + | ZBIO-99999 | does not exist | valid | 404 | + | SECRET-1 | exists but user has no browse permission | valid but insufficient permissions | 403 | + + # Test case: TC-JIRA-003 - Invalid credentials returns 401/403 + # Combined with TC-JIRA-023 (wrong auth scheme) + @TC-JIRA-003 @TC-JIRA-023 @negative + Scenario Outline: Fetch with invalid authentication returns 401 + Given a valid JIRA issue ID "" exists in the system + And the authentication header is set to "" + When I send a GET request to "/issue/" + Then the response status should be 401 + And the error log should contain "Failed to get details for JIRA-ID: with error: AxiosError: Request failed with status code 401" + Examples: + | issue_id | auth_header | + | ZBIO-7718 | invalid token | + | ZBIO-7718 | Basic base64(user:token) (wrong scheme) | + + # Test case: TC-JIRA-015 - Missing JIRA_TOKEN environment variable + @TC-JIRA-015 @negative + Scenario: Fetch with missing JIRA_TOKEN environment variable fails with configuration error + Given the JIRA_TOKEN environment variable is not set + And a JIRA issue ID "PROJ-123" + When I attempt to fetch the issue + Then no HTTP request should be made + And the log should contain an ERROR entry with "Missing required environment variable: JIRA_TOKEN" + + # Test case: TC-JIRA-005 - Concurrent fetch race condition + @TC-JIRA-005 @end-to-end @concurrency + Scenario: Concurrent fetch of the same existing JIRA ID should not produce false 404s + Given a valid JIRA issue ID "ZBIO-7718" exists + When I send 10 simultaneous GET requests to "/issue/ZBIO-7718" + Then all responses should have status 200 + And no response should have status 404 + And the log should contain INFO entries for each successful request + + # Test case: TC-JIRA-006 - Network timeout and retry + @TC-JIRA-006 @error-handling + Scenario: Fetch with network timeout triggers timeout error and retry logic + Given the API base URL points to a mock server that delays response beyond the configured timeout + And the timeout is set to 5000 milliseconds + When I send a GET request to "/issue/ZBIO-7718" + Then the request should timeout after 5000 milliseconds + And the log should contain "AxiosError: timeout of 5000ms exceeded" + And if retry is configured, the log should show retry attempts + And the test should fail gracefully without crash + + # Test case: TC-JIRA-007 - Malformed base URL (connection error) + @TC-JIRA-007 @integration + Scenario: Fetch with malformed JIRA_BASE_URL results in connection error + Given the API base URL is set to "http://invalid-domain.nonexistent" + And a valid JIRA issue ID "PROJ-123" + When I send a GET request to "/issue/PROJ-123" + Then the request should fail with a network error + And the log should contain "Failed to get details for JIRA-ID: PROJ-123 with error: AxiosError: request failed" and include "ENOTFOUND" or similar + And no HTTP status code should be logged + + # Test case: TC-JIRA-008 - Credential expires mid-suite + @TC-JIRA-008 @state-transition + Scenario: Credential expiry mid-suite is handled and suite continues + Given I have a test suite with three sequential fetches + And the first fetch uses valid token T1 + And the second fetch uses an expired token T2 + And the third fetch uses valid token T1 again + When the test suite runs + Then the first fetch should succeed with INFO log + And the second fetch should fail with 401 and ERROR log + And the third fetch should succeed with INFO log + And the suite should not abort and report one failure + + # Test case: TC-JIRA-009 - Audit log for successful fetch (log content) + @TC-JIRA-009 @positive @audit + Scenario: Successful fetch log contains required fields for audit trail + Given a valid JIRA issue ID "ZBIO-7718" exists + When I send a GET request to "/issue/ZBIO-7718" + Then the log should contain an INFO entry with the JIRA ID, HTTP 200, timestamp in ISO 8601 format, and optionally a correlation ID + + # Test case: TC-JIRA-010 - Cross-stack environment configuration drift + @TC-JIRA-010 @integration + Scenario Outline: Fetches from different stacks use correct JIRA_BASE_URL + Given the system runs on stack "" with JIRA_BASE_URL "" + And a known existing issue ID "PROJ-123" exists in that JIRA instance + When I send a GET request to "/issue/PROJ-123" + Then the actual HTTP request URL should start with "" + Examples: + | stack_name | base_url | + | stack1 | https://jira-stack1.atlassian.net | + | stack2 | https://jira-stack2.atlassian.net | + + # Test case: TC-JIRA-011 - Retry on HTTP 500 + @TC-JIRA-011 @error-handling @retry + Scenario: Fetch with transient HTTP 500 triggers retry and eventual success + Given the API base URL points to a mock server that returns HTTP 500 for first 2 requests and HTTP 200 for the third + And the retry policy is configured with 3 retries + When I send a GET request to "/issue/ZBIO-7718" + Then the request should succeed after retries + And the log should contain ERROR entries for the first two attempts with status code 500 + And the log should contain an INFO entry for the third attempt with status 200 + + # Test case: TC-JIRA-012 - API version mismatch + @TC-JIRA-012 @integration + Scenario: Fetch using incorrect JIRA API version returns appropriate error + Given the API base URL includes "/rest/api/3" instead of "/rest/api/2" + And a valid JIRA issue ID "ZBIO-7718" exists + When I send a GET request to "/rest/api/3/issue/ZBIO-7718" + Then the response status should be 404 (or 405) + And the error log should contain the received status code + + # Test case: TC-JIRA-013, TC-JIRA-017, also covers TC-JIRA-004 (boundary for special characters and max length) + @TC-JIRA-013 @TC-JIRA-017 @TC-JIRA-004 @boundary @negative + Scenario Outline: Fetch with invalid JIRA ID formats fails gracefully + Given the system has valid credentials + And the JIRA ID is set to "" + When I send a GET request to "/issue/" + Then the request should either be rejected before HTTP call with a validation error + Or if sent, the log should contain an error with the exact ID format + And the test suite should not crash + Examples: + | jira_id | expected_behavior | + | (empty string) | validation error: "Invalid JIRA ID: empty" or similar; no HTTP request | + | null | validation error or Axios error with malformed URL | + | " ZBIO-7718 " | either trimmed and successful fetch, or validation error about whitespace | + | "PROJ_123" | if JIRA does not accept underscore, error logged with full ID; if exists, success | + | "PROJ-123456789012345" (30 chars) | if non-existent, error log contains full ID without truncation; if exists, success | + + # Test case: TC-JIRA-014 - HTTP 429 rate limiting + @TC-JIRA-014 @error-handling @rate-limit + Scenario: Fetch with HTTP 429 rate limiting response is handled + Given the API base URL points to a mock server that returns HTTP 429 with Retry-After: 5 + When I send a GET request to "/issue/ZBIO-7718" + Then the system should either wait 5 seconds and retry, or fail immediately + And if retry occurs, log should show "Retrying after 5000ms due to 429" + If no retry, log should contain "Request failed with status code 429" + And the test should not crash + + # Test case: TC-JIRA-016 - Decision table for combinations of credential validity and ID existence + @TC-JIRA-016 @decision-table + Scenario Outline: Systematic test of credential validity vs JIRA ID existence + Given the credentials are "" + And the JIRA ID "" + When I send a GET request to "/issue/" + Then the response status should be + And the log should contain entry with appropriate message + Examples: + | credential_type | jira_id | existence | expected_status | log_type | + | valid | ZBIO-7718 | exists | 200 | INFO | + | valid | ZBIO-99999 | does not exist | 404 | ERROR | + | invalid/expired | ZBIO-7718 | exists | 401/403 | ERROR | + | invalid/expired | ZBIO-99999 | does not exist | 401/403 | ERROR | + + # Test case: TC-JIRA-018 - Log format consistency across error types + @TC-JIRA-018 @regression @log-format + Scenario Outline: Error log format consistency for different error types + Given the API base URL points to a mock server that returns for a valid issue ID "ZBIO-7718" + When I send a GET request to "/issue/ZBIO-7718" + Then the error log should exactly match "Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: Request failed with status code " + Examples: + | http_status | + | 401 | + | 403 | + | 404 | + | 500 | + + # Test case: TC-JIRA-020 - Credential rotation mid-suite + @TC-JIRA-020 @state-transition + Scenario: Sequential fetches with credential rotation between requests + Given a test suite that performs two fetches consecutively + And the first fetch uses valid token T1 + And between fetches, the token is changed to another valid token T2 + When the first fetch is for issue "ZBIO-7718" and the second fetch is for the same issue + Then both fetches should succeed with HTTP 200 + And the logs should reflect that each request used the correct token (if discernible) + + # Test case: TC-JIRA-021 - Redirect handling + @TC-JIRA-021 @integration + Scenario: HTTP redirect from JIRA API is followed correctly + Given the API base URL points to a mock server that returns HTTP 301 with Location: + And the real JIRA server is accessible + When I send a GET request to "/issue/ZBIO-7718" + Then the system should follow the redirect and eventually receive HTTP 200 + And the log should contain an INFO entry with final HTTP 200 + + # Test case: TC-JIRA-022 - HTTP 200 with error body + @TC-JIRA-022 @error-handling + Scenario: HTTP 200 with error body in response is treated as failure + Given the API base URL points to a mock server that returns HTTP 200 with body containing error messages (e.g., {"errorMessages":["Issue does not exist"]}) + When I send a GET request to "/issue/ZBIO-99999" + Then the fetch should be considered a failure + And the log should contain an ERROR entry with "Invalid response: issue not found" or similar + And no INFO success log should be present + + # Test case: TC-JIRA-024 - Eventual consistency (newly created issue) + @TC-JIRA-024 @end-to-end @eventual-consistency + Scenario: Fetch a newly created JIRA issue immediately to test eventual consistency + Given I create a new JIRA issue via API with project "ZBIO" and summary "Test eventual consistency" + And I immediately issue a GET request for the new issue ID + Then the first request may return HTTP 404 or 200 + When I retry after 2 seconds + Then the second request should return HTTP 200 (if issue propagated) + And error logs should not cause crash + And the newly created issue should be deleted after test + + # Test case: TC-JIRA-025 - Error log audit trail verification + @TC-JIRA-025 @audit + Scenario: Error log contains mandatory audit fields + Given a non-existent JIRA issue ID "ZBIO-99999" + When I send a GET request to "/issue/ZBIO-99999" + Then the error log should contain: timestamp in ISO 8601, JIRA ID "ZBIO-99999", HTTP status 404, and optionally a correlation ID + + # Test case: TC-JIRA-026 - HTTP 204 No Content + @TC-JIRA-026 @error-handling + Scenario: Fetch receives HTTP 204 No Content and logs error + Given the API base URL points to a mock server that returns HTTP 204 for issue "ZBIO-7718" + When I send a GET request to "/issue/ZBIO-7718" + Then the fetch should fail + And the log should contain an ERROR entry with "Empty response with status 204" or "Unexpected HTTP status: 204" + And the system should not crash + + # Test case: TC-JIRA-027 - HTTP 200 with missing required fields + @TC-JIRA-027 @error-handling + Scenario: HTTP 200 response missing mandatory fields is treated as failure + Given the API base URL points to a mock server that returns HTTP 200 with JSON body missing "id" field for issue "ZBIO-7718" + When I send a GET request to "/issue/ZBIO-7718" + Then the fetch should fail + And the log should contain an ERROR entry with "Response missing required field: id" + And no success log + + # Test case: TC-JIRA-028 - SSL certificate error + @TC-JIRA-028 @error-handling @ssl + Scenario: SSL certificate validation failure logs connection error + Given the API base URL points to a server with a self-signed certificate (SSL reject enabled) + When I send a GET request to "/issue/ZBIO-7718" + Then the request should fail with an SSL error + And the log should contain "Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: self signed certificate" (or similar) + + # Test case: TC-JIRA-029 - Sequential fetches of multiple IDs + @TC-JIRA-029 @functional @independence + Scenario: Sequential fetches of different JIRA IDs are independent + Given I have three JIRA IDs: existing "ZBIO-7718", existing "PROJ-123", non-existing "ZBIO-99999" + When I fetch each ID sequentially + Then the first fetch returns 200 with INFO log for "ZBIO-7718" + And the second fetch returns 200 with INFO log for "PROJ-123" + And the third fetch returns 404 with ERROR log for "ZBIO-99999" + And each log entry contains the correct JIRA ID + + # Test case: TC-JIRA-030 - Extremely short timeout + @TC-JIRA-030 @error-handling @timeout + Scenario: Extremely short timeout (1ms) causes immediate timeout error + Given the timeout is set to 1 millisecond + And a valid JIRA issue ID "ZBIO-7718" + When I send a GET request to "/issue/ZBIO-7718" + Then the request should timeout immediately + And the log should contain "AxiosError: timeout of 1ms exceeded" + And the test should not hang diff --git a/functional_tests/ZBIO-7758/ZBIO-7758.json b/functional_tests/ZBIO-7758/ZBIO-7758.json new file mode 100644 index 0000000..40f7c55 --- /dev/null +++ b/functional_tests/ZBIO-7758/ZBIO-7758.json @@ -0,0 +1,398 @@ +[ + { + "type": "functional", + "title": "Fetch existing JIRA issue with valid credentials and known ID", + "description": "Verify successful retrieval of JIRA issue details on stack1.roost.ai using valid credentials and a known, existing JIRA ID.", + "testId": "TC-JIRA-001", + "testDescription": "Given the system has valid JIRA credentials and a known issue ZBIO-7718, when the fetch function is called on stack1.roost.ai, then the response should include issue details without error.", + "prerequisites": "Valid JIRA credentials stored in environment variables (JIRA_BASE_URL, JIRA_USER, JIRA_TOKEN), JIRA issue ZBIO-7718 exists in the connected project, system deployed on stack1.roost.ai", + "stepsToPerform": "1. Verify environment variables JIRA_BASE_URL is set to correct stack1 URL (e.g., https://your-jira-instance.atlassian.net). 2. Verify JIRA_USER and JIRA_TOKEN are valid and not expired. 3. Initiate a functional test suite that triggers fetch for ZBIO-7718. 4. Wait for the test suite to execute completely. 5. Check the application logs for any error entries. 6. Verify that no 404 or other HTTP error is logged. 7. Capture the response payload (if accessible) and assert it contains fields: id, key, summary, status. 8. Confirm that the test suite reports success and no retries occurred.", + "expectedResult": "Test suite passes; log shows successful retrieval (INFO level); response contains issue details for ZBIO-7718; no error messages.", + "assumptions": "ASSUMPTION: JIRA instance is reachable and ZBIO-7718 exists at the time of execution." + }, + { + "type": "error-handling", + "title": "Fetch non-existent JIRA ID returns 404 with exact error message", + "description": "Verify that requesting a JIRA ID that does not exist results in a 404 error and logs the exact error message as seen in the original bug report.", + "testId": "TC-JIRA-002", + "testDescription": "Using a non-existent JIRA ID (e.g., ZBIO-99999), the system must return a 404 error and log the exact message format: 'Failed to get details for JIRA-ID: with error: AxiosError: Request failed with status code 404'.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-99999 does not exist in the system, environment variable JIRA_BASE_URL points to a reachable JIRA instance", + "stepsToPerform": "1. Set up the test suite to fetch details for JIRA ID ZBIO-99999. 2. Execute the test. 3. Observe the test failure. 4. Inspect the application log for the error message. 5. Verify the log contains exactly 'Failed to get details for JIRA-ID: ZBIO-99999 with error: AxiosError: Request failed with status code 404'. 6. Confirm there is no additional stack trace or crash. 7. Check that the test suite does not hang or timeout indefinitely. 8. Assert that subsequent tests in the suite continue to run without impact.", + "expectedResult": "Test case fails with expected error; log contains mandatory error message; no unhandled exceptions; other tests continue.", + "httpStatusExpected": "404", + "logLevel": "ERROR" + }, + { + "type": "negative", + "title": "Fetch JIRA issue with expired or invalid credentials returns 401/403", + "description": "Verify that when JIRA credentials are expired or invalid, the system logs a 401/403 error with the proper format and does not crash.", + "testId": "TC-JIRA-003", + "testDescription": "Given the system has invalid JIRA credentials (e.g., expired token), when the fetch function is called for any JIRA ID, then the system must return an authentication error and log the exact error message.", + "prerequisites": "JIRA credentials set to invalid values (e.g., expired token, wrong password), JIRA_ID = PROJ-123 exists, environment variables set accordingly", + "stepsToPerform": "1. Override JIRA_TOKEN with an expired or invalid token. 2. Initiate a fetch for JIRA ID PROJ-123. 3. Execute the test. 4. Check the application log for error entries. 5. Verify the log contains 'Failed to get details for JIRA-ID: PROJ-123 with error: AxiosError: Request failed with status code 401' (or 403). 6. Confirm no crash or hang occurs. 7. Restore valid credentials after test. 8. Ensure the test suite reports failure for this test but continues.", + "expectedResult": "Test case fails; error logged with status 401/403; system remains stable; credential errors are handled gracefully.", + "httpStatusExpected": "401,403", + "credentialType": "invalid/expired", + "logLevel": "ERROR" + }, + { + "type": "boundary", + "title": "Boundary test for JIRA ID format – special characters and maximum length", + "description": "Verify that the system correctly handles JIRA IDs with special characters (underscores, hyphens) and IDs at maximum allowed length (e.g., 30 characters) without breaking the error message format or causing unhandled exceptions.", + "testId": "TC-JIRA-004", + "testDescription": "Using a JIRA ID with underscores (e.g., PROJ_123) and a long ID (e.g., PROJECTKEY-9999999999 – 30 chars), the system should either fetch successfully (if it exists) or log the exact error message without truncation or malformation.", + "prerequisites": "Valid JIRA credentials, two JIRA IDs pre-configured in the test: one with underscore (PROJ_123) – may not exist, one with 30 characters (e.g., PROJ-123456789012345) – likely non-existent", + "stepsToPerform": "1. Prepare two test cases: one with ID 'PROJ_123', another with ID 'PROJ-123456789012345'. 2. Execute the test suite with both IDs. 3. Observe the results and logs for each. 4. For each ID, verify the log message (if error) contains the exact ID without truncation. 5. If the ID exists, verify successful fetch. If not, verify error message format is correct. 6. Confirm no character encoding issues or crashes. 7. Check that the error message length does not exceed acceptable log limits. 8. Assert that the test suite handles both cases gracefully.", + "expectedResult": "For non-existent IDs, error message includes full ID; for existing IDs, successful retrieval; no crashes or misformatted logs.", + "jiraIdFormat": "alphanumeric with special chars, max length 30", + "assumptions": "ASSUMPTION: JIRA does not accept underscores in project keys; system may treat them as invalid; we are testing system's resilience." + }, + { + "type": "end-to-end", + "title": "Concurrent fetch of same JIRA ID to simulate race condition leading to transient 404", + "description": "Simulate a race condition by sending multiple concurrent fetch requests for the same JIRA ID. Verify that the system handles concurrency without false 404 errors and that all responses are consistent.", + "testId": "TC-JIRA-005", + "testDescription": "Given the system has valid credentials and a known existing JIRA ID, when multiple parallel fetch requests are issued, then all responses should succeed or fail consistently, and any 404 errors should be legitimate (ID does not exist). This test aims to reproduce the non-reproducible bug.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718 exists, test environment with ability to send concurrent HTTP requests (e.g., using async/await in test script)", + "stepsToPerform": "1. Create a test script that fires 10 simultaneous fetch requests for ZBIO-7718. 2. Execute the script on stack1.roost.ai. 3. Collect all responses and errors. 4. Count how many requests succeeded (2xx) and how many failed (4xx/5xx). 5. If any 404 occurs, capture the exact error message from logs. 6. Check that the logs contain exactly the same error message format for any failure. 7. Verify that the test suite itself does not crash or hang. 8. Repeat the test 3 times to check flakiness.", + "expectedResult": "All requests either succeed (2xx) or fail with consistent errors; if any 404 appears, it is legitimate (but unlikely since ID exists); system logs all attempts; no unhandled exceptions; non-reproducible bug may be reproduced if race condition exists.", + "networkCondition": "concurrent requests", + "assumptions": "ASSUMPTION: The JIRA API may have rate limiting or throttling; concurrency test may trigger different behaviors." + }, + { + "type": "error-handling", + "title": "Fetch JIRA issue with network timeout simulates transient failure and retry logic", + "description": "Verify that when the JIRA API request times out, the system logs a timeout error, retries according to configured logic, and eventually fails with a clear error message or succeeds on retry.", + "testId": "TC-JIRA-006", + "testDescription": "Given the system has valid credentials and a known JIRA ID, when the network is manipulated to cause a timeout (e.g., using a mock that delays response beyond timeout), then the system must log the timeout error, perform retries if enabled, and either succeed on retry or log failure with AxiosError timeout message.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718 exists, test environment supports network delay injection (e.g., mock server or proxy), timeout configured in system (e.g., 5 seconds)", + "stepsToPerform": "1. Configure a mock or proxy that introduces a 30-second delay before returning a response. 2. Initiate a fetch for JIRA ID ZBIO-7718 with valid credentials. 3. Observe the request timing; expect timeout after configured timeout value. 4. Check application logs: verify error message contains 'AxiosError: timeout of Xms exceeded' (or similar) and includes JIRA ID. 5. If retry is configured, verify that up to N retries are logged with timestamps. 6. After retries, verify the final error log does not crash the test suite. 7. Remove network delay and re-run to confirm successful behavior returns. 8. Confirm that the test suite continues with subsequent tests.", + "expectedResult": "System logs timeout error with correct format, retries (if configured) are visible in logs, test fails gracefully, no crash or hang.", + "httpStatusExpected": "0 (timeout)", + "networkCondition": "simulated timeout", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system has a configurable timeout and retry mechanism. If not, test verifies immediate failure without retry." + }, + { + "type": "integration", + "title": "Fetch JIRA issue with malformed base URL leads to DNS/connection error", + "description": "Verify that when the JIRA_BASE_URL is misconfigured (e.g., missing 'https://', extra characters, or unreachable host), the system logs a connection error with the exact message and does not crash.", + "testId": "TC-JIRA-007", + "testDescription": "Given the system reads JIRA_BASE_URL from an environment variable, when the URL is set to an invalid value (e.g., 'http//wrong-url'), then the fetch should fail with a connection error and log 'AxiosError: request failed' or 'ENOTFOUND' without throwing an unhandled exception.", + "prerequisites": "JIRA credentials valid, but JIRA_BASE_URL set to malformed value (e.g., 'http://invalid-domain.nonexistent/api'), JIRA ID = PROJ-123 (any)", + "stepsToPerform": "1. Set environment variable JIRA_BASE_URL to 'http://invalid-domain.nonexistent'. 2. Trigger fetch for JIRA ID PROJ-123. 3. Observe the test outcome. 4. Inspect application logs for error entry. 5. Verify the log message contains 'Failed to get details for JIRA-ID: PROJ-123 with error: AxiosError: request failed' and includes the error description (e.g., 'ENOTFOUND', 'getaddrinfo'). 6. Confirm that no stack trace is printed to stdout. 7. Check that the test suite does not hang and reports failure. 8. After test, restore JIRA_BASE_URL to correct value and verify success.", + "expectedResult": "Test fails with connection error logged; system remains stable; error message includes JIRA ID and underlying network error.", + "httpStatusExpected": "N/A (network error)", + "credentialType": "valid", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system uses Axios and does not validate the URL before sending request." + }, + { + "type": "state-transition", + "title": "Credential expires mid-test suite – verify error handling and suite continuation", + "description": "Simulate a scenario where JIRA token expires during execution of a test suite. Verify that the system logs a 401 error for the affected fetch, does not crash, and continues with subsequent tests that may use refreshed credentials.", + "testId": "TC-JIRA-008", + "testDescription": "Given a functional test suite with multiple test cases, when the first test uses a token that expires before the second test runs, the second test should fail with 401, log the error, and the suite should continue to the third test that uses a valid token.", + "prerequisites": "JIRA credentials, ability to expire token mid-suite (e.g., by rotating token or using a mock), test suite with at least 3 sequential fetch tests", + "stepsToPerform": "1. Prepare a test suite with 3 tests: Test A uses token T1 (valid), Test B uses token T2 (expired/revoked), Test C uses token T1 again (still valid). 2. Execute the suite. 3. Observe Test A succeeds. 4. Observe Test B fails; check logs for 'AxiosError: Request failed with status code 401' with correct JIRA ID. 5. Verify that Test B's failure does not abort the suite. 6. Observe Test C succeeds (since valid token is still valid). 7. Inspect log for each test: ensure error log only appears for Test B. 8. Confirm the suite reports Test B as failed, others as passed.", + "expectedResult": "Test A passes, Test B fails with 401 error logged correctly, Test C passes, suite does not crash or stop prematurely.", + "httpStatusExpected": "401", + "credentialType": "expired mid-suite", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The token is passed per request and not cached globally; token expiry does not cause cascading failures." + }, + { + "type": "end-to-end", + "title": "Audit trail verification for successful JIRA fetch – log content check", + "description": "Verify that after a successful JIRA fetch, the audit log contains all required fields: JIRA ID, HTTP status 200, timestamp, and correlation ID (if available). This ensures observability requirements are met.", + "testId": "TC-JIRA-009", + "testDescription": "Given the system successfully fetches a JIRA issue, then the log entry for that operation must include at least JIRA ID, HTTP status code (200), timestamp in a parseable format, and correlation ID if the system generates one.", + "prerequisites": "Valid JIRA credentials, existing JIRA issue ZBIO-7718, log aggregation accessible (e.g., file, stdout), the system must generate correlation IDs for each fetch (if not, skip correlation ID check)", + "stepsToPerform": "1. Trigger fetch for JIRA ID ZBIO-7718. 2. Wait for completion and ensure success. 3. Capture the log line corresponding to the successful fetch (look for INFO level). 4. Parse the log to extract: JIRA ID (ZBIO-7718), HTTP status (200), timestamp, correlation ID (if present). 5. Verify that all required fields are present and correctly formatted. 6. Verify timestamp is within expected time range (before and after the fetch). 7. If correlation ID exists, verify it is a non-empty string and unique for this request. 8. Repeat for a different existing JIRA ID to ensure consistency.", + "expectedResult": "Log entry is of INFO level, contains 'JIRA-ID: ZBIO-7718', 'HTTP 200', a timestamp, and optionally a correlation ID. No errors are logged.", + "httpStatusExpected": "200", + "logLevel": "INFO", + "assumptions": "ASSUMPTION: Successful fetches are logged at INFO level. Correlation ID is generated if the system includes middleware for that." + }, + { + "type": "integration", + "title": "Cross-stack environment configuration drift – different JIRA base URLs", + "description": "Verify that the system correctly reads the JIRA_BASE_URL from environment-specific configuration and that switching stacks (e.g., stack1 vs stack2) uses the correct endpoint without mixing settings.", + "testId": "TC-JIRA-010", + "testDescription": "Given the system runs on two different stacks (stack1.roost.ai and stack2.roost.ai), when the same test is executed on each stack with different JIRA base URLs configured, the API calls must be made to the correct URLs and results should be consistent per environment.", + "prerequisites": "Access to two environments (stack1 and stack2) with different JIRA base URLs, valid credentials per environment, a JIRA ID that exists in both JIRA instances (or same instance accessible from both stacks), ability to inspect outgoing HTTP requests (network logs or proxy)", + "stepsToPerform": "1. On stack1, set JIRA_BASE_URL to 'https://jira-stack1.atlassian.net'. 2. Execute fetch for JIRA ID PROJ-123 on stack1. 3. Capture the actual HTTP request URL from network logs. 4. Assert that the URL starts with 'https://jira-stack1.atlassian.net/rest/api/...'. 5. On stack2, set JIRA_BASE_URL to 'https://jira-stack2.atlassian.net'. 6. Execute fetch for same JIRA ID on stack2. 7. Capture the request URL and verify it starts with 'https://jira-stack2.atlassian.net/...'. 8. Confirm that responses are appropriately returned (if JIRA instances have same data, results should match; if not, handle accordingly).", + "expectedResult": "Each stack uses its own configured base URL; requests are sent to the correct JIRA instance; logs reflect the correct endpoint; no cross-contamination of environment variables.", + "credentialType": "valid per stack", + "assumptions": "ASSUMPTION: The JIRA_BASE_URL environment variable is read at runtime and not hardcoded. Both stacks are properly configured with distinct URLs." + }, + { + "type": "error-handling", + "title": "Retry logic verification on HTTP 500 from JIRA API", + "description": "Verify that when JIRA returns a transient 500 server error, the system retries according to configured retry count and interval, and logs each attempt with the correct error format before eventually failing.", + "testId": "TC-JIRA-011", + "testDescription": "Given the system has valid credentials and a known JIRA ID ZBIO-7718, when the JIRA API is manipulated to return HTTP 500 for the first two attempts and then a 200 on the third attempt, then the system should retry and succeed, or if all retries fail, log the final error with status 500.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718 exists in the system, test environment supports HTTP stubbing (e.g., mock server or wiremock) to return configurable responses for consecutive requests, retry policy is enabled (e.g., 3 retries with 1 sec delay)", + "stepsToPerform": "1. Configure a mock JIRA API endpoint that returns HTTP 500 for the first 2 requests and HTTP 200 for the third request. 2. Set environment variables for JIRA_BASE_URL to point to the mock. 3. Initiate a fetch for JIRA ID ZBIO-7718. 4. Observe the test outcome – expect success after retries. 5. Inspect application logs: verify that the first two attempts are logged as 'Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: Request failed with status code 500' each. 6. Verify that the third attempt log shows INFO level success. 7. Confirm that the retry count and intervals are logged (if applicable). 8. Disable retries and repeat with 500 always to verify that final error is logged after zero retries.", + "expectedResult": "System retries up to configured number, logs each failure in exact format, succeeds on retry if mock returns 200, or fails permanently if all retries exhaust. Test suite does not crash.", + "httpStatusExpected": "500 (transient), 200 (after retry)", + "networkCondition": "simulated server error", + "logLevel": "ERROR (initial attempts), INFO (success on retry)", + "assumptions": "ASSUMPTION: System has configurable retry logic with exponential backoff or fixed interval. If no retry, test verifies immediate failure." + }, + { + "type": "integration", + "title": "JIRA API version mismatch – v2 vs v3 endpoint", + "description": "Verify that using an incorrect JIRA API version path (e.g., /rest/api/3 instead of /rest/api/2) results in an appropriate error message and does not crash the system.", + "testId": "TC-JIRA-012", + "testDescription": "Given the system is configured with JIRA_BASE_URL pointing to 'https://jira-instance.atlassian.net/rest/api/3', when the fetch function is called for a valid JIRA ID, then the system should receive an error (e.g., 404 if endpoint not found, or 405 method not allowed) and log the exact message including the status code.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718 exists, JIRA_BASE_URL is set to incorrect version (e.g., /rest/api/3), the JIRA instance does not support API v3 or returns an error", + "stepsToPerform": "1. Set environment variable JIRA_BASE_URL to 'https://your-jira-instance.atlassian.net/rest/api/3'. 2. Trigger fetch for JIRA ID ZBIO-7718. 3. Observe the test outcome (expect failure). 4. Check the application logs for error entry. 5. Verify the log message contains 'Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: Request failed with status code 404' (or 405, 400). 6. Confirm that the error message includes the actual status code returned by the API. 7. Verify no other components (e.g., thread pool) are affected. 8. Restore correct URL and confirm success.", + "expectedResult": "Test fails with appropriate HTTP error (likely 404) logged in the correct format; system remains stable; no unhandled exceptions.", + "httpStatusExpected": "404, 405, or 400", + "credentialType": "valid", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The JIRA instance does not support API v3; response is 404 or client error. If v3 is supported, test may succeed – adjust expected status accordingly." + }, + { + "type": "negative", + "title": "Fetch with empty or null JIRA ID – graceful error handling", + "description": "Verify that providing an empty string or null value as JIRA ID does not cause an unhandled exception, crash, or infinite loop, and that a clear validation error is logged.", + "testId": "TC-JIRA-013", + "testDescription": "Given the system expects a non-empty JIRA ID string, when the JIRA ID parameter is empty or null, then the system should reject the request before making an HTTP call, log a meaningful error, and not crash.", + "prerequisites": "Valid JIRA credentials, test suite ability to call fetch with invalid parameters (empty string '' or null), no mocking required", + "stepsToPerform": "1. Prepare a test case where JIRA ID is set to an empty string ''. 2. Execute the fetch. 3. Observe the test outcome (expect immediate failure). 4. Check the application logs for any error message. 5. Verify that the error message contains the empty ID representation (e.g., '' or '(empty)') and does not attempt an HTTP request. 6. Confirm that no HTTP call was made to JIRA (can be checked via network proxy). 7. Repeat with JIRA ID set to null (if applicable, depending on how parameter is passed). 8. Ensure the test suite does not hang and continues with next test.", + "expectedResult": "Test fails immediately with a validation error logged; no HTTP request made; system remains stable; no stack trace printed to stdout.", + "jiraIdFormat": "empty or null", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system has a validation step before making the HTTP call. If not, test will verify that an Axios error with malformed URL is logged instead." + }, + { + "type": "error-handling", + "title": "Simulate HTTP 429 rate limiting response from JIRA", + "description": "Verify that when JIRA returns HTTP 429 (Too Many Requests), the system either respects the Retry-After header (if implemented) or logs the error and fails gracefully without making aggressive retries that could worsen rate limiting.", + "testId": "TC-JIRA-014", + "testDescription": "Given the system has valid credentials and a known JIRA ID, when the JIRA API returns HTTP 429 with a Retry-After header (e.g., 5 seconds), then the system should either pause and retry after the indicated delay, or immediately fail with a clear log message containing status 429.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718, ability to mock HTTP 429 response with Retry-After header, test environment with network proxy or mock server", + "stepsToPerform": "1. Configure a mock JIRA API endpoint to return HTTP 429 status with Retry-After: 5. 2. Set JIRA_BASE_URL to point to the mock. 3. Initiate a fetch for ZBIO-7718. 4. Observe the test behavior – check if the system waits 5 seconds and retries, or fails immediately. 5. If retry occurs, verify logs show a retry attempt after delay (e.g., 'Retrying after 5000ms due to 429'). 6. If immediate failure, verify log contains 'AxiosError: Request failed with status code 429'. 7. Confirm that no more than one retry is made (to avoid flooding). 8. Repeat without Retry-After header to verify default behavior.", + "expectedResult": "System either respects Retry-After and retries successfully, or logs the 429 error immediately without crash. Test suite handles gracefully.", + "httpStatusExpected": "429", + "networkCondition": "simulated rate limiting", + "logLevel": "ERROR (or INFO if retry)", + "assumptions": "ASSUMPTION: The system may or may not implement retry on 429. Test documents both behaviors." + }, + { + "type": "negative", + "title": "Missing JIRA_TOKEN environment variable – graceful initialization failure", + "description": "Verify that when the JIRA_TOKEN environment variable is not set (empty or missing), the system logs a descriptive error before making any API call and does not crash or hang.", + "testId": "TC-JIRA-015", + "testDescription": "Given the system requires JIRA_TOKEN to be set for authentication, when the variable is missing, then the fetch function should detect the missing configuration, log a clear error (e.g., 'Missing required environment variable: JIRA_TOKEN'), and return without attempting an HTTP call.", + "prerequisites": "JIRA_BASE_URL and JIRA_USER set, but JIRA_TOKEN unset (removed from environment), JIRA ID = PROJ-123 (any), the system should validate credentials before making HTTP requests", + "stepsToPerform": "1. Remove or unset the JIRA_TOKEN environment variable from the test environment. 2. Trigger a fetch for JIRA ID PROJ-123. 3. Observe the test outcome (expect immediate failure). 4. Check the application logs for any error entry. 5. Verify that the log message contains 'Missing required environment variable: JIRA_TOKEN' or similar, and does NOT contain any HTTP error. 6. Confirm that no HTTP request was sent to JIRA (can verify via network logs or mock). 7. Re-set JIRA_TOKEN to a valid value. 8. Re-run the test to confirm successful fetch returns.", + "expectedResult": "Test fails with a configuration error logged; no HTTP call made; system does not crash; after restoring variable, success.", + "credentialType": "missing", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: System performs validation of environment variables at startup or before each request. If not, test will show Axios error due to missing auth header." + }, + { + "type": "decision-table", + "title": "Systematic combination test: credential validity vs JIRA ID existence", + "description": "Use decision table testing to verify all four combinations of credential validity (valid/invalid) and JIRA ID existence (exists/not exists). Ensure that authentication failure takes precedence over 404 and that the correct error message is logged for each case.", + "testId": "TC-JIRA-016", + "testDescription": "Given a test suite that fetches JIRA details for four combinations: (valid creds + existing ID), (valid creds + non-existing ID), (invalid creds + existing ID), (invalid creds + non-existing ID). Then verify that each combination produces the expected HTTP status and log message, and that the suite does not crash.", + "prerequisites": "Valid JIRA credentials (token T_valid), invalid/expired token (T_invalid), existing JIRA ID (ZBIO-7718), non-existing JIRA ID (ZBIO-99999), test environment with ability to switch credentials between runs (e.g., via environment variable override)", + "stepsToPerform": "1. Configure test with T_valid and ZBIO-7718. Execute fetch. Assert success (HTTP 200) and INFO log. 2. Configure test with T_valid and ZBIO-99999. Execute fetch. Assert failure with HTTP 404 and exact error log message. 3. Configure test with T_invalid and ZBIO-7718. Execute fetch. Assert failure with HTTP 401 (or 403) and exact error log. 4. Configure test with T_invalid and ZBIO-99999. Execute fetch. Assert failure with HTTP 401 (or 403) since auth error takes precedence, and exact error log. 5. Verify that the error log in steps 2-4 follows the format 'Failed to get details for JIRA-ID: with error: AxiosError: Request failed with status code '. 6. Confirm that no unhandled exceptions or crashes occur in any combination. 7. Ensure that the test suite runs all four combinations sequentially and does not hang. 8. Restore valid credentials and confirm that a simple fetch succeeds.", + "expectedResult": "Four test results: 1 pass, 3 fails with correct HTTP status and log messages. System remains stable across all combinations.", + "httpStatusExpected": "200,404,401/403,401/403", + "credentialType": "valid and invalid", + "jiraIdType": "existing and non-existing", + "logLevel": "INFO for success, ERROR for failures", + "assumptions": "ASSUMPTION: The system checks authentication before checking existence, so invalid credentials always yield 401/403 regardless of JIRA ID. If the system checks existence first, then combination 4 might yield 404 instead – test documents actual behavior." + }, + { + "type": "boundary", + "title": "JIRA ID with leading/trailing whitespace – trimming behavior", + "description": "Verify that the system handles JIRA IDs that contain leading or trailing whitespace by either trimming them before sending the request or logging a meaningful validation error without crash.", + "testId": "TC-JIRA-017", + "testDescription": "Given a known existing JIRA ID like ZBIO-7718, when the input ID contains extra spaces (e.g., ' ZBIO-7718 '), then the system should either trim the spaces and successfully retrieve the issue or reject the input with a clear validation error message.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718 exists, ability to pass ID with spaces (through test script or direct API call)", + "stepsToPerform": "1. Prepare a test case with JIRA ID = ' ZBIO-7718 ' (leading and trailing space). 2. Execute the fetch. 3. Observe the outcome. 4. If successful, verify that the log shows the trimmed ID (e.g., 'ZBIO-7718') and no error. 5. If failure, check the log for a validation error like 'Invalid JIRA ID: contains whitespace' or similar. 6. Confirm that no HTTP request is made if validation fails. 7. If trimming is implemented, repeat with only leading space, only trailing space, and multiple spaces. 8. Ensure the test suite does not crash and continues to next tests.", + "expectedResult": "Either the fetch succeeds after trimming (log shows trimmed ID) or fails with a validation error before HTTP call. No unhandled exceptions.", + "jiraIdFormat": "with leading/trailing whitespace", + "logLevel": "ERROR if validation fails, INFO if trimming succeeds", + "assumptions": "ASSUMPTION: The system may or may not trim. This test documents current behavior." + }, + { + "type": "regression", + "title": "Log format consistency across different error types (401, 403, 404, 500, timeout)", + "description": "Verify that the error log message format is identical for all supported HTTP error codes and timeouts, following the pattern: 'Failed to get details for JIRA-ID: with error: AxiosError: Request failed with status code ' (or 'timeout of Xms exceeded' for timeouts).", + "testId": "TC-JIRA-018", + "testDescription": "Using mocks to return specific HTTP errors (401, 403, 404, 500) and a network timeout, verify that each error produces a log message with exactly the same structure and includes the correct status code or timeout description.", + "prerequisites": "Valid JIRA credentials, a known JIRA ID (ZBIO-7718 or any), mock server capable of returning configurable HTTP status codes and simulating timeouts, ability to capture application logs", + "stepsToPerform": "1. Set JIRA_BASE_URL to a mock server that returns HTTP 401 for the first request. 2. Trigger fetch for ZBIO-7718. 3. Capture the log error message. 4. Assert the message matches 'Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: Request failed with status code 401'. 5. Change mock to return HTTP 403, repeat steps 2-4, expect status code 403. 6. Repeat for HTTP 404 and 500. 7. For timeout: configure mock to delay response beyond timeout (e.g., 30 sec). Expect log message like 'Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: timeout of 5000ms exceeded'. 8. Verify that all log messages follow the same pattern and include the JIRA ID and the exact error description.", + "expectedResult": "All error logs conform to the required format with appropriate status code or timeout message. No variations or extra line breaks.", + "httpStatusExpected": "401,403,404,500,timeout", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system uses Axios and logs errors consistently. Timeout message format may vary slightly; test documents exact format observed." + }, + { + "type": "negative", + "title": "Fetch JIRA issue from a project the user does not have access to (403 forbidden)", + "description": "Verify that when the authenticated user does not have permission to view a JIRA issue (e.g., in a restricted project), the system returns a 403 error and logs the correct message without exposing any issue fields.", + "testId": "TC-JIRA-019", + "testDescription": "Given valid JIRA credentials that lack read permission on a specific project, when the fetch function is called for a valid issue ID in that project, then the system must log a 403 error with the exact format and must not include any issue data in the response.", + "prerequisites": "Valid JIRA credentials for a user that does not have 'Browse Projects' permission on project 'SECRET', a known existing JIRA ID in that project (e.g., SECRET-1), ability to identify such an ID (test data setup)", + "stepsToPerform": "1. Identify a JIRA project that the test user cannot access. Obtain a real issue ID (e.g., SECRET-1) that exists. 2. Configure the test to fetch SECRET-1 using the test credentials. 3. Execute the fetch. 4. Observe the test outcome (expect failure with 403). 5. Check the application log for the error message. 6. Verify the log contains 'Failed to get details for JIRA-ID: SECRET-1 with error: AxiosError: Request failed with status code 403'. 7. Confirm that no issue fields (summary, description, etc.) are printed or logged. 8. Ensure that the test suite does not crash and continues with subsequent tests.", + "expectedResult": "Test fails with HTTP 403 error logged in correct format. No issue data leakage. System stable.", + "httpStatusExpected": "403", + "credentialType": "valid but insufficient permissions", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: A test JIRA project with restricted access is available. If not, simulate with a mock returning 403." + }, + { + "type": "functional", + "title": "Sequential fetches with credential rotation between requests", + "description": "Verify that the system reads JIRA credentials at request time and does not cache them, so that rotating the token between two consecutive fetches works correctly: first fetch uses old token, second uses new token.", + "testId": "TC-JIRA-020", + "testDescription": "Given a test suite that performs two sequential fetches, and the JIRA token is changed in between (from T1 to T2), then the first fetch should succeed with T1, and the second fetch should succeed with T2 without mixing credentials.", + "prerequisites": "Two valid JIRA tokens (T1 and T2) that both have access to the same issue (ZBIO-7718), environment variable JIRA_TOKEN is read at request time (not cached at startup), ability to update environment variable mid-test (e.g., via process.env modification or script)", + "stepsToPerform": "1. Set JIRA_TOKEN to T1 (valid). 2. Execute first fetch for ZBIO-7718. Assert success. 3. Immediately change JIRA_TOKEN to T2 (also valid). 4. Execute second fetch for same ZBIO-7718. Assert success. 5. Inspect logs: verify that first fetch used T1 (if possible via audit log) and second used T2. 6. If audit logs do not show token, verify that no authentication errors occurred. 7. Repeat with T1 then invalid T2 to confirm that second fetch fails with 401, proving that the new token is used. 8. Ensure that the test suite does not crash due to credential change.", + "expectedResult": "Both fetches succeed if both tokens are valid. If T2 is invalid, second fetch fails with 401. Logs show correct operation. No caching of credentials.", + "credentialType": "rotated mid-suite", + "logLevel": "INFO for success, ERROR for failure", + "assumptions": "ASSUMPTION: The environment variable JIRA_TOKEN is read on each request. If the system reads it only at startup, this test will fail and reveal caching behavior." + }, + { + "type": "integration", + "title": "HTTP redirect handling when JIRA API returns 301/302", + "description": "Verify that the system correctly follows an HTTP redirect (301/302) from the JIRA API and either retrieves the issue successfully or logs the final status code if the redirect fails.", + "testId": "TC-JIRA-021", + "testDescription": "Given a JIRA ID that has been moved to a new URL, when the system sends a fetch request, the JIRA API returns a 301/302 redirect. The system should follow the redirect (Axios default) and succeed (HTTP 200) or log an error if the redirect leads to a failure.", + "prerequisites": "Valid JIRA credentials, mock server returning 301 to a valid endpoint for ZBIO-7718, or a real JIRA issue that triggers a redirect (e.g., issue moved to a different project). Access to application logs.", + "stepsToPerform": "1. Configure a mock JIRA endpoint that returns HTTP 301 with a Location header pointing to the actual ZBIO-7718 endpoint on a real JIRA instance. 2. Set JIRA_BASE_URL to the mock. 3. Initiate a fetch for ZBIO-7718. 4. Observe the HTTP request flow (e.g., via proxy or network log) to see the redirect. 5. Capture the application logs. 6. Verify that the system follows the redirect and receives a final HTTP 200. 7. Check logs for INFO level success containing JIRA ID ZBIO-7718 and HTTP 200 (or a message indicating redirect was followed). 8. If redirect leads to an error (e.g., 404), verify that the error log contains the final status code and JIRA ID. 9. Repeat with mock returning 302 to an invalid endpoint to ensure error is logged. 10. Confirm test suite does not hang and reports appropriate pass/fail.", + "expectedResult": "System follows redirect by default; logs show successful retrieval or error with final status code. No unhandled exceptions.", + "httpStatusExpected": "301 (redirect), 200 (final success) or error code", + "networkCondition": "redirect", + "logLevel": "INFO on success, ERROR on failure", + "assumptions": "ASSUMPTION: System uses Axios which follows redirects by default (maxRedirects: 5). If redirect leads to a non-2xx final status, error is logged. Test may use mock server." + }, + { + "type": "negative", + "title": "JIRA API returns HTTP 200 with error body indicating issue not found", + "description": "Verify that the system does not blindly trust HTTP 200 and validates the response body for actual success indicators, logging an error if the response indicates a failure.", + "testId": "TC-JIRA-022", + "testDescription": "Given a JIRA API that returns HTTP 200 but the response body contains an error message (e.g., 'Issue not found' or empty fields), the system should detect the inconsistency and log an error rather than treating it as success.", + "prerequisites": "Valid JIRA credentials, mock server configured to return HTTP 200 with a body like {'errorMessages': ['Issue does not exist']} or empty response, JIRA ID = ZBIO-99999 (non-existent) but server returns 200 to test validation.", + "stepsToPerform": "1. Configure a mock JIRA endpoint that returns HTTP 200 with a JSON body containing an error message (e.g., {'errorMessages':['Issue does not exist'], 'errors':{}}). 2. Set JIRA_BASE_URL to the mock. 3. Trigger fetch for JIRA ID ZBIO-99999. 4. Capture the application logs and response handling. 5. Verify that the system does not treat this as a successful fetch. 6. Check logs for an ERROR entry containing the JIRA ID and a message like 'Invalid response: issue not found' or similar. 7. Confirm that no INFO level success is logged. 8. Repeat with a mock returning HTTP 200 with empty body – verify same behavior. 9. Ensure the test suite does not crash. 10. Restore mock to normal behavior and verify success.", + "expectedResult": "System detects invalid response body and logs an error, even though HTTP status is 200. No crash.", + "httpStatusExpected": "200 (but treated as failure)", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system checks the response body for expected fields (e.g., id, key). If it only relies on HTTP status, this test will pass as success – test documents actual behavior." + }, + { + "type": "error-handling", + "title": "Incorrect authentication header format (Bearer vs Basic) returns 401", + "description": "Verify that if the system sends an authentication header in the wrong format (e.g., Basic instead of Bearer for an API token), the JIRA API returns 401 and the system logs the correct error message.", + "testId": "TC-JIRA-023", + "testDescription": "Given valid JIRA credentials stored as a token, but the system mistakenly encodes them as a Basic auth header (base64 of username:token), the JIRA API will reject with 401. The system must log 'Failed to get details for JIRA-ID: with error: AxiosError: Request failed with status code 401'.", + "prerequisites": "Valid JIRA token, ability to modify how the system constructs the Authorization header (e.g., via environment flag or code change), JIRA ID = ZBIO-7718 exists, test environment can intercept or mock to confirm header format.", + "stepsToPerform": "1. Configure the system to use Basic authentication (base64 of JIRA_USER:JIRA_TOKEN) instead of Bearer token. 2. Initiate a fetch for ZBIO-7718. 3. Capture the HTTP request headers (e.g., via proxy or network log). 4. Verify that the Authorization header starts with 'Basic '. 5. Observe the test outcome – expect 401. 6. Check application logs for error message containing status code 401. 7. Confirm the error message format is exact. 8. Restore correct Bearer token authentication. 9. Repeat with correct header to confirm success. 10. Ensure test suite continues without issue.", + "expectedResult": "Test fails with HTTP 401; error log contains correct format; after restoring correct header, success. No crash.", + "httpStatusExpected": "401", + "credentialType": "valid token but wrong auth scheme", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system has a configuration option for auth type. If not, this test may require code modification. Alternatively, use a mock that returns 401 for Basic auth." + }, + { + "type": "end-to-end", + "title": "Fetch newly created JIRA issue immediately to test eventual consistency", + "description": "Reproduce the non-reproducible 404 by creating a new JIRA issue and immediately fetching it. Verify that the system either succeeds or logs a 404 due to replication delay, and that retries can resolve it.", + "testId": "TC-JIRA-024", + "testDescription": "Given a JIRA instance with eventual consistency (e.g., multiple nodes), when a new issue is created and immediately fetched, the first fetch may return 404. The system should handle either outcome gracefully, with proper logging and optional retry.", + "prerequisites": "JIRA API access with permissions to create issues, JIRA project from which the ID is generated (e.g., ZBIO), valid credentials, test automation to create an issue via API and then immediately fetch it multiple times.", + "stepsToPerform": "1. Use JIRA API to create a new issue (e.g., project ZBIO, summary 'Test eventual consistency'). Capture the new issue ID (e.g., ZBIO-7720). 2. Immediately (within 1 second) trigger a fetch for that new issue ID. 3. Observe the first fetch response. 4. If it returns 404, check the log for error message with status 404 and note the timestamp. 5. Retry the fetch after 2 seconds. 6. If the second fetch succeeds (200), verify log shows INFO success. 7. If both fail with 404, log the failure but ensure system does not crash. 8. Repeat steps 1-7 for 3 different newly created issues to assess consistency. 9. Delete the created issues after test. 10. Ensure test suite reports pass/fail accurately and does not hang.", + "expectedResult": "System handles transient 404 gracefully; if issue becomes available after delay, success logged; if not, error logged. No crash or infinite retries.", + "httpStatusExpected": "may be 404 initially, then 200", + "logLevel": "ERROR if 404, INFO if success", + "assumptions": "ASSUMPTION: The JIRA instance may have replication delay. If the instance is synchronous, always succeeds. This test is designed to detect eventual consistency issues that could cause the original bug." + }, + { + "type": "end-to-end", + "title": "Error log audit trail verification – ensure all error logs contain correlation ID, timestamp, JIRA ID, and status code", + "description": "Verify that for every failed JIRA fetch, the error log includes mandatory fields: correlation ID (if available), timestamp, JIRA ID, and HTTP status code (or error description). This ensures observability requirements are met for debugging.", + "testId": "TC-JIRA-025", + "testDescription": "Given the system logs errors during failed JIRA fetches, when a fetch fails due to 404 (non-existent ID) or 401 (invalid credentials), the error log must contain: timestamp, JIRA ID, HTTP status code, and correlation ID (if the system generates one). This test checks the structure of error logs.", + "prerequisites": "Valid and invalid JIRA credentials, access to system logs (e.g., file or stdout), knowledge of log format (e.g., JSON or structured). The system should generate a correlation ID for each request (if not, skip that field).", + "stepsToPerform": "1. Trigger a fetch with a non-existent JIRA ID (e.g., ZBIO-99999) and valid credentials. 2. Capture the resulting error log line from the log output. 3. Parse the log to extract fields: timestamp, JIRA ID, HTTP status code (404), correlation ID (if present). 4. Verify that timestamp is present and in a recognizable format (e.g., ISO 8601). 5. Verify that JIRA ID is present and matches the input. 6. Verify that HTTP status code is present and equals 404. 7. If correlation ID exists, verify it is a non-empty string. 8. Repeat the same steps with invalid credentials (401) and a valid JIRA ID to ensure consistency. 9. Check that no other essential fields are missing. 10. Confirm that the error log is at ERROR level and no additional stack trace is printed in the same line (unless intentional).", + "expectedResult": "All error logs contain timestamp, JIRA ID, HTTP status code, and optionally correlation ID. Format is consistent across different error types.", + "httpStatusExpected": "404, 401", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system includes correlation IDs in logs. If not, test verifies only timestamp, JIRA ID, and status code. Log format may be JSON or plain text; parsing accordingly." + }, + { + "type": "error-handling", + "title": "JIRA API returns HTTP 204 No Content – system logs appropriate error", + "description": "Verify that when the JIRA API returns a 204 No Content response (e.g., for an issue with no details), the system does not treat it as success and logs an error with the proper message.", + "testId": "TC-JIRA-026", + "testDescription": "Given valid JIRA credentials and a valid JIRA ID, when the JIRA API returns HTTP 204 No Content, then the system must log an error containing the JIRA ID and a descriptive message (e.g., 'Empty response with status 204') and must not crash.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718 exists in the system, mock JIRA server that returns HTTP 204 for the specific endpoint, environment variable JIRA_BASE_URL points to the mock server", + "stepsToPerform": "1. Configure a mock JIRA API endpoint to return HTTP 204 No Content for any issue detail request. 2. Set JIRA_BASE_URL to point to the mock. 3. Initiate a fetch for JIRA ID ZBIO-7718. 4. Observe the test outcome (expect failure). 5. Capture the application logs. 6. Verify that the error log contains the JIRA ID (ZBIO-7718). 7. Verify that the error log does not contain a status code from Axios (since 204 is not an error for Axios), but the system should detect the empty response and log a custom error like 'Empty response with status 204' or 'Unexpected HTTP status: 204'. 8. Confirm that no subsequent tests are affected and the test suite reports failure. 9. Restore the mock to return HTTP 200 and verify successful fetch. 10. Ensure no unhandled exceptions or crashes.", + "expectedResult": "Test fails; error log contains JIRA ID and indicates empty response or unexpected status; system stable.", + "httpStatusExpected": "204", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system expects a non-empty JSON response with issue fields. If the system treats 204 as success (e.g., no content), then this test will pass incorrectly – test documents actual behavior." + }, + { + "type": "error-handling", + "title": "JIRA API returns HTTP 200 but response lacks mandatory fields – validation failure", + "description": "Verify that when the JIRA API returns HTTP 200 with a JSON body that is missing required fields (e.g., id, key, summary), the system detects the invalid response and logs an error without crashing.", + "testId": "TC-JIRA-027", + "testDescription": "Given valid credentials and a known JIRA ID, when the JIRA API returns HTTP 200 with a JSON object that omits critical fields (like 'id' or 'summary'), then the system must not treat it as success. It should log an error describing the missing fields and fail gracefully.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718, mock JIRA server returning HTTP 200 with a partial JSON body (e.g., {'key':'ZBIO-7718'} but no 'id' or summary), ability to intercept application logs", + "stepsToPerform": "1. Configure a mock JIRA endpoint to return HTTP 200 with JSON body: {'key':'ZBIO-7718', 'status':'Open'} but missing 'id', 'summary', 'description'. 2. Set JIRA_BASE_URL to the mock. 3. Initiate a fetch for ZBIO-7718. 4. Observe the test outcome (expect failure). 5. Capture application logs. 6. Verify that the error log contains the JIRA ID and a message indicating missing required fields (e.g., 'Response missing required field: id'). 7. Confirm that no HTTP status error is logged (since status is 200). 8. Verify that the system does not attempt to process the incomplete data further. 9. Repeat with a response missing only 'summary' – expect similar validation error. 10. Ensure the test suite does not crash and continues.", + "expectedResult": "Test fails; error log describes missing fields; system does not crash; no success log.", + "httpStatusExpected": "200 (treated as failure)", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system validates the response structure and requires certain fields. If it blindly accepts any 200 response, this test will pass as success – test documents actual behavior." + }, + { + "type": "error-handling", + "title": "SSL/TLS certificate validation failure – system logs connection error", + "description": "Verify that when the JIRA server presents an invalid or self-signed SSL certificate (e.g., during man-in-the-middle simulation), the system logs a connection error with the JIRA ID and does not crash.", + "testId": "TC-JIRA-028", + "testDescription": "Given the JIRA_BASE_URL points to a server with an invalid SSL certificate (self-signed, expired, or mismatched domain), when the fetch function is called for a JIRA ID, the system should fail with an Axios error related to SSL (e.g., 'CERT_HAS_EXPIRED' or 'UNABLE_TO_VERIFY_LEAF_SIGNATURE') and log the error in the expected format.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718, ability to configure a mock HTTPS server with a self-signed certificate (or use an actual server with invalid cert), environment variable JIRA_BASE_URL set to that server, NODE_TLS_REJECT_UNAUTHORIZED should be set to '0' to allow bypass? Actually for testing we need it set to '1' to cause failure. Or we can use a mock that forces SSL error.", + "stepsToPerform": "1. Set up a mock HTTPS server with a self-signed certificate. 2. Set JIRA_BASE_URL to the mock server's URL (https://...). 3. Ensure Node.js environment has NODE_TLS_REJECT_UNAUTHORIZED=1 (or default). 4. Initiate a fetch for ZBIO-7718. 5. Observe the test outcome (expect failure). 6. Check application logs for error entry. 7. Verify the log contains 'Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: self signed certificate' (or similar SSL error). 8. Confirm that no HTTP status code is logged (since no HTTP response received). 9. Ensure the test suite does not hang and reports failure. 10. Optionally, repeat with NODE_TLS_REJECT_UNAUTHORIZED=0 to confirm that SSL bypass allows success (if applicable).", + "expectedResult": "Test fails; error log contains JIRA ID and Axios SSL error; no crash; system reports failure.", + "httpStatusExpected": "N/A (SSL error)", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system runs in a Node.js environment that performs SSL validation by default. If SSL verification is disabled, this test will not trigger an error – adjust accordingly." + }, + { + "type": "functional", + "title": "Sequential fetches of multiple different JIRA IDs in one test suite – isolation and independence", + "description": "Verify that the system can fetch details for multiple distinct JIRA IDs sequentially within the same test suite without interference, and that each fetch is logged independently with the correct ID and status.", + "testId": "TC-JIRA-029", + "testDescription": "Given a functional test suite that performs three sequential fetches for different JIRA IDs (e.g., ZBIO-7718 existing, PROJ-123 existing in another project, and ZBIO-99999 non-existing), then each fetch should produce its own log entry with the correct JIRA ID and HTTP status, and the success/failure of one should not affect the others.", + "prerequisites": "Valid JIRA credentials, at least two existing JIRA IDs (ZBIO-7718 and PROJ-123) and one non-existing ID (ZBIO-99999), test suite configured to run three fetch tests in sequence", + "stepsToPerform": "1. Prepare a test suite with three test cases: Test A: fetch ZBIO-7718, Test B: fetch PROJ-123, Test C: fetch ZBIO-99999. 2. Execute the suite. 3. Observe Test A – should succeed (HTTP 200). 4. Observe Test B – should succeed (HTTP 200, different project). 5. Observe Test C – should fail with HTTP 404. 6. Inspect application logs for each test: verify that each log entry contains the correct JIRA ID. 7. Confirm that the success logs for Test A and Test B are at INFO level and contain HTTP 200. 8. Confirm that the error log for Test C is at ERROR level and contains HTTP 404 and the exact error format. 9. Verify that no test’s output or logs contain a different ID by mistake (cross-contamination). 10. Ensure the suite reports Test A and B as passed, Test C as failed, and does not crash.", + "expectedResult": "Tests A and B pass; Test C fails with 404; all logs correctly associated with each JIRA ID; no interference.", + "httpStatusExpected": "200 (for A and B), 404 (for C)", + "logLevel": "INFO for success, ERROR for failure", + "assumptions": "ASSUMPTION: The system does not cache or share state between fetch calls. Each request is independent. Test B's project may require the same credentials to have access; if not, adjust to an accessible ID." + }, + { + "type": "error-handling", + "title": "Extremely short timeout causes immediate timeout error", + "description": "Verify that when the HTTP request timeout is set to an extremely low value (e.g., 1ms), the system logs a timeout error immediately, does not hang, and continues with subsequent tests.", + "testId": "TC-JIRA-030", + "testDescription": "Given the system's HTTP client timeout is configured to 1 millisecond, when a fetch request is made for a JIRA ID, the request will timeout almost instantly (since the network round-trip is >1ms). The system must log an Axios timeout error containing the JIRA ID and 'timeout of 1ms exceeded' and not crash.", + "prerequisites": "Valid JIRA credentials, JIRA ID ZBIO-7718, ability to set the HTTP timeout in the system configuration (e.g., via environment variable TIMEOUT_MS=1), the JIRA server must have a response time greater than 1ms (which is virtually always true)", + "stepsToPerform": "1. Set the HTTP timeout environment variable (e.g., JIRA_API_TIMEOUT=1). 2. Initiate a fetch for ZBIO-7718. 3. Observe the test outcome – expect immediate failure (within milliseconds). 4. Check application logs for error entry. 5. Verify the log message contains 'Failed to get details for JIRA-ID: ZBIO-7718 with error: AxiosError: timeout of 1ms exceeded' (or similar). 6. Confirm that no HTTP request was actually sent (optional: check network logs). 7. Verify that the test suite does not hang and quickly reports failure. 8. Restore the timeout to a normal value (e.g., 5000ms). 9. Re-run the fetch to confirm success with normal timeout. 10. Ensure that the test suite continues with subsequent tests without delay.", + "expectedResult": "Test fails immediately; error log contains timeout message with JIRA ID; no hang; after restoring timeout, fetch succeeds.", + "httpStatusExpected": "N/A (timeout)", + "networkCondition": "extremely short timeout", + "logLevel": "ERROR", + "assumptions": "ASSUMPTION: The system allows configuration of HTTP timeout via environment variable. If not, this test may require code modification. Test documents system behavior under extreme timeout." + } +] \ No newline at end of file diff --git a/functional_tests/ZBIO-7758/ZBIO-7758.xlsx b/functional_tests/ZBIO-7758/ZBIO-7758.xlsx new file mode 100644 index 0000000..65c6848 Binary files /dev/null and b/functional_tests/ZBIO-7758/ZBIO-7758.xlsx differ