Skip to content

AI: Adds a new /generate-tests Claude command that automates the generation of integration tests#2706

Open
chiragkyal wants to merge 1 commit intoopenshift:masterfrom
chiragkyal:claude-generate-test
Open

AI: Adds a new /generate-tests Claude command that automates the generation of integration tests#2706
chiragkyal wants to merge 1 commit intoopenshift:masterfrom
chiragkyal:claude-generate-test

Conversation

@chiragkyal
Copy link
Member

Summary

  • Adds a new /generate-tests Claude command that automates the generation of comprehensive .testsuite.yaml integration test files for OpenShift API type definitions

Description

This PR introduces a Claude command for generating integration tests for any API group/version in the repository. The command:

  1. Analyzes API types - Reads Go type definitions, extracts validation markers, CEL rules, kubebuilder annotations, enum types, and discriminated unions
  2. Reads CRD manifests - Examines zz_generated.featuregated-crd-manifests/ to understand CRD variants, defaults, and OpenAPI v3 schemas
  3. Preserves existing tests - Checks existing test coverage and only adds tests for new or modified fields
  4. Generates comprehensive test suites covering:
    • Minimal valid create tests
    • Valid/invalid field value tests
    • Enum validation tests
    • Pattern and constraint validation
    • Feature-gated field tests
    • Update and immutability tests
    • Validation ratcheting tests
  5. Validates output - Ensures generated YAML is syntactically correct

Usage

/generate-tests <path-to-types-file-or-api-directory>

Examples:

/generate-tests config/v1/types_infrastructure.go
/generate-tests operator/v1

Signed-off-by: chiragkyal <ckyal@redhat.com>
@openshift-ci-robot
Copy link

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@qodo-code-review
Copy link

Review Summary by Qodo

Add /generate-tests Claude command for API integration test generation

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Adds /generate-tests Claude command for automated integration test generation
• Analyzes Go types, validation markers, CRD manifests, and CEL rules
• Generates comprehensive .testsuite.yaml test suites for API variants
• Covers minimal valid creates, field validation, updates, immutability, and feature gates
• Preserves existing tests and only adds tests for new or modified fields
Diagram
flowchart LR
  A["API Types & CRD Manifests"] -->|Extract validation rules| B["Analyze Types"]
  B -->|Read existing tests| C["Check Coverage"]
  C -->|Generate test suites| D["Create .testsuite.yaml"]
  D -->|Validate YAML| E["Output Test Files"]
Loading

Grey Divider

File Changes

1. .claude/commands/generate-tests.md ✨ Enhancement +398/-0

New generate-tests command with comprehensive test generation logic

• New Claude command definition for generating integration test suites
• Implements 7-step workflow: prechecks, identify types, understand existing tests, generate suites,
 write files, verify, and summarize
• Defines test categories covering minimal valid creates, field validation, updates, immutability,
 singletons, discriminated unions, feature gates, status subresources, and validation ratcheting
• Includes behavioral rules for deriving test values from source, matching existing style, including
 defaults, and preserving existing tests

.claude/commands/generate-tests.md


2. AGENTS.md 📝 Documentation +14/-0

Document generate-tests command usage and examples

• Adds documentation for the new /generate-tests command in the Custom Claude Code Commands
 section
• Includes command syntax, description of functionality, and usage examples

AGENTS.md


Grey Divider

Qodo Logo

@coderabbitai
Copy link

coderabbitai bot commented Feb 12, 2026

📝 Walkthrough

Walkthrough

Two documentation files were added to describe a new test generation workflow for OpenShift API types. A new file .claude/commands/generate-tests.md (398 lines) documents a comprehensive command interface that specifies how to generate integration test suites, including prechecks, type discovery, test generation logic across CRD variants, YAML test file format specifications, and verification steps. The file AGENTS.md was updated (14 lines added) to introduce the "Generate Tests" command with usage examples and descriptions of inputs from Go types and CRD manifests, and outputs to test suite files.

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The PR title accurately summarizes the main change: adding a new /generate-tests Claude command for automating integration test generation for OpenShift API types.
Description check ✅ Passed The PR description is well-related to the changeset, providing clear details about the new /generate-tests command, its functionality, usage examples, and the comprehensive test generation capabilities it provides.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Comment @coderabbitai help to get the list of available commands and usage tips.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 12, 2026

Hello @chiragkyal! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

@openshift-ci openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Feb 12, 2026
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@AGENTS.md`:
- Around line 129-140: The fenced code blocks in the AGENTS.md snippet (the
usage line "/generate-tests <path-to-types-file-or-api-directory>" and the
example lines "/generate-tests config/v1/types_infrastructure.go" and
"/generate-tests operator/v1") are missing language identifiers and trigger
MD040; update each triple-backtick fence around these blocks to include a
language token like "text" (i.e., change the opening ``` to ```text for the
three code fences that surround the usage line and the example block) so the
markdown linter no longer flags them.

Comment on lines +129 to +140
```
/generate-tests <path-to-types-file-or-api-directory>
```
Generates comprehensive `.testsuite.yaml` integration test files for OpenShift API type definitions:
- Reads Go types, validation markers, CRD manifests, and CEL rules
- Generates test suites for each CRD variant in `zz_generated.featuregated-crd-manifests/`

Examples:
```
/generate-tests config/v1/types_infrastructure.go
/generate-tests operator/v1
```
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Add language identifiers to fenced code blocks.

Markdownlint MD040 is triggered because these fences omit a language; add one (e.g., text) to keep lint clean.

🛠️ Proposed fix
-```
+```text
 /generate-tests <path-to-types-file-or-api-directory>
-```
+```
 ...
-```
+```text
 /generate-tests config/v1/types_infrastructure.go
 /generate-tests operator/v1
-```
+```
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)

[warning] 129-129: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


[warning] 137-137: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents
In `@AGENTS.md` around lines 129 - 140, The fenced code blocks in the AGENTS.md
snippet (the usage line "/generate-tests <path-to-types-file-or-api-directory>"
and the example lines "/generate-tests config/v1/types_infrastructure.go" and
"/generate-tests operator/v1") are missing language identifiers and trigger
MD040; update each triple-backtick fence around these blocks to include a
language token like "text" (i.e., change the opening ``` to ```text for the
three code fences that surround the usage line and the example block) so the
markdown linter no longer flags them.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 12, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign everettraven for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@qodo-code-review
Copy link

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (2) 📎 Requirement gaps (0)

Grey Divider


Action required

1. TARGET_PATH lacks validation 📘 Rule violation ⛨ Security
Description
The command uses user-provided TARGET_PATH to derive API_DIR without verifying the path exists
or is within the repo root, which can lead to unintended file reads/scans outside the repository.
This violates the requirement to validate and sanitize external inputs.
Code

.claude/commands/generate-tests.md[R18-40]

+REPO_ROOT=$(git rev-parse --show-toplevel)
+TARGET_PATH="$ARGUMENTS"
+if [ -z "$TARGET_PATH" ]; then
+  echo "PRECHECK FAILED: No target path provided."
+  echo "Usage: /generate-tests <path-to-types-file-or-api-directory>"
+  echo "Examples:"
+  echo "  /generate-tests config/v1/types_infrastructure.go"
+  echo "  /generate-tests operator/v1"
+  echo "  /generate-tests route/v1/types_route.go"
+  exit 1
+fi
+
+echo "Repository root: $REPO_ROOT"
+echo "Target: $TARGET_PATH"
+```
+
+```bash
+if [ -d "$TARGET_PATH" ]; then
+  API_DIR="$TARGET_PATH"
+else
+  API_DIR=$(dirname "$TARGET_PATH")
+fi
+```
Evidence
PR Compliance ID 6 requires validating/sanitizing external inputs; the added command accepts
arbitrary TARGET_PATH from ARGUMENTS and derives API_DIR via dirname with no
existence/repo-boundary checks before later filesystem operations use it.

Rule 6: Generic: Security-First Input Validation and Data Handling
.claude/commands/generate-tests.md[18-40]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `/generate-tests` command consumes user-provided `TARGET_PATH` without validating existence or constraining it to the git repository root, enabling accidental or malicious reads/scans outside the repo.

## Issue Context
`TARGET_PATH` is derived from `ARGUMENTS` and then used to compute `API_DIR` with `dirname`, but there are no checks like `test -e`, `realpath`, or prefix checks against `$REPO_ROOT`.

## Fix Focus Areas
- .claude/commands/generate-tests.md[18-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. featureGate key ignored 🐞 Bug ✓ Correctness
Description
The command instructs using featureGate: for single-gate variants, but the test suite loader only
reads featureGates (slice). Generated gated suites will be treated as ungated and run against all
CRD variants, causing incorrect coverage and potential false failures.
Code

.claude/commands/generate-tests.md[R115-129]

+For feature-gated variants, add the gate(s):
+
+```yaml
+# Single feature gate:
+featureGate: <FeatureGateName>
+
+# Multiple feature gates:
+featureGates:
+- <FeatureGate1>
+- <FeatureGate2>
+
+# Negative gates (enabled in ungated but not when this gate is active):
+featureGates:
+- -<FeatureGateName>
+```
Evidence
SuiteSpec only has FeatureGates []string with JSON/YAML key featureGates; YAML is unmarshaled
directly into this struct, so featureGate is ignored. When FeatureGates is empty,
perTestRuntimeInfo treats the test as ungated and includes all CRD files for that CRD name.

.claude/commands/generate-tests.md[115-129]
tests/types.go[4-15]
tests/generator.go[61-70]
tests/crd_filter.go[48-52]
image/v1/tests/ImageStreamImportMode.yaml[1-5]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`/generate-tests` currently instructs generating `featureGate: &lt;name&gt;` for single-gated variants, but the test runner’s `SuiteSpec` only consumes `featureGates` (slice). As a result, single-gated suites generated from these instructions will be treated as ungated.

### Issue Context
The YAML loader unmarshals directly into `SuiteSpec` and filtering logic checks `len(featureGates)==0` to decide whether a suite is ungated.

### Fix Focus Areas
- .claude/commands/generate-tests.md[115-129]
- .claude/commands/generate-tests.md[392-394]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Incorrect manifest/output paths 🐞 Bug ✓ Correctness
Description
The command references zz_generated.featuregated-crd-manifests/<plural>.<group>/ and outputs to
<group>/<version>/tests/..., but in-repo featuregated manifests and suites are located under the
API directory (e.g., security/v1/zz_generated.featuregated-crd-manifests/... and
security/v1/tests/...). Following the doc literally can cause “not found” variant discovery and
tests written to paths the runner won’t load.
Code

.claude/commands/generate-tests.md[R70-104]

+Read the types file(s) and extract all information. Also read the corresponding CRD manifests
+from `zz_generated.featuregated-crd-manifests/<plural>.<group>/` to get:
+- The list of CRD variants (ungated, per-featureGate, compound)
+- The full CRD name
+- Default values applied by the schema
+- The full OpenAPI v3 validation tree
+
+## Step 3: Understand Existing Tests
+
+Check the `tests/` directory for existing test suites:
+
+```bash
+# List existing test files for this CRD
+TEST_DIR="$API_DIR/tests"
+if [ -d "$TEST_DIR" ]; then
+  echo "=== Existing test directories ==="
+  ls -la "$TEST_DIR/"
+fi
+```
+
+If test files already exist for this CRD, read them to understand existing coverage.
+Do NOT duplicate tests that already exist. Only add tests for NEW or MODIFIED fields/types.
+
+## Step 4: Generate Test Suites
+
+For each CRD variant found in `zz_generated.featuregated-crd-manifests/<plural>.<group>/`,
+generate a corresponding test file at:
+
+```text
+<group>/<version>/tests/<plural>.<group>/<VariantName>.yaml
+```
+
+Where `<VariantName>` matches the CRD manifest filename (e.g., `AAA_ungated.yaml`,
+`OnPremDNSRecords.yaml`, `FeatureA+FeatureB.yaml`).
+
Evidence
Repo tooling iterates featuregated CRD manifests under
${FOLDER}/zz_generated.featuregated-crd-manifests (where FOLDER is an API dir like security/v1)
and writes suites under ${FOLDER}/tests/.... A concrete example exists under
security/v1/zz_generated.featuregated-crd-manifests/... and corresponding security/v1/tests/....

.claude/commands/generate-tests.md[70-100]
tests/hack/gen-minimal-test.sh[23-46]
security/v1/zz_generated.featuregated-crd-manifests/securitycontextconstraints.security.openshift.io/AAA_ungated.yaml[1-14]
security/v1/tests/securitycontextconstraints.security.openshift.io/AAA_ungated.yaml[1-4]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The command’s documented paths are ambiguous/wrong relative to this repo’s layout: featuregated CRD manifests and generated suites live under the specific API directory (like `security/v1/...`), not at repo root, and `&lt;group&gt;` is overloaded (API group domain vs directory name).

### Issue Context
Existing repo tooling (`tests/hack/gen-minimal-test.sh`) demonstrates the expected layout and will be what developers mirror.

### Fix Focus Areas
- .claude/commands/generate-tests.md[70-76]
- .claude/commands/generate-tests.md[93-104]
- .claude/commands/generate-tests.md[301-309]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. python YAML check hides errors 📘 Rule violation ⛯ Reliability
Description
The YAML verification loop suppresses Python/YAML parsing errors (2>/dev/null) and uses `for f in
$(find ...)`, which can break on whitespace and makes failures harder to diagnose. This reduces
robustness and weakens edge case handling for verification.
Code

.claude/commands/generate-tests.md[R317-321]

+for f in $(find "$API_DIR/tests" -name '*.yaml' -type f); do
+  if ! python3 -c "import yaml; yaml.safe_load(open('$f'))" 2>/dev/null; then
+    echo "WARNING: Invalid YAML in $f"
+  fi
+done
Evidence
PR Compliance ID 3 requires robust error handling and explicit edge case management; the added
verification snippet both suppresses the underlying error output and uses a whitespace-splitting
loop construct that is fragile for filenames.

Rule 3: Generic: Robust Error Handling and Edge Case Management
.claude/commands/generate-tests.md[317-321]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The YAML verification loop is fragile for filenames and suppresses error details needed to understand why verification failed.

## Issue Context
The snippet uses `for f in $(find ...)` (word-splitting) and redirects Python stderr to `/dev/null`, which can mask missing dependencies (e.g., PyYAML) and actual parse errors.

## Fix Focus Areas
- .claude/commands/generate-tests.md[317-321]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment on lines +18 to +40
REPO_ROOT=$(git rev-parse --show-toplevel)
TARGET_PATH="$ARGUMENTS"
if [ -z "$TARGET_PATH" ]; then
echo "PRECHECK FAILED: No target path provided."
echo "Usage: /generate-tests <path-to-types-file-or-api-directory>"
echo "Examples:"
echo " /generate-tests config/v1/types_infrastructure.go"
echo " /generate-tests operator/v1"
echo " /generate-tests route/v1/types_route.go"
exit 1
fi

echo "Repository root: $REPO_ROOT"
echo "Target: $TARGET_PATH"
```

```bash
if [ -d "$TARGET_PATH" ]; then
API_DIR="$TARGET_PATH"
else
API_DIR=$(dirname "$TARGET_PATH")
fi
```

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. target_path lacks validation 📘 Rule violation ⛨ Security

The command uses user-provided TARGET_PATH to derive API_DIR without verifying the path exists
or is within the repo root, which can lead to unintended file reads/scans outside the repository.
This violates the requirement to validate and sanitize external inputs.
Agent Prompt
## Issue description
The `/generate-tests` command consumes user-provided `TARGET_PATH` without validating existence or constraining it to the git repository root, enabling accidental or malicious reads/scans outside the repo.

## Issue Context
`TARGET_PATH` is derived from `ARGUMENTS` and then used to compute `API_DIR` with `dirname`, but there are no checks like `test -e`, `realpath`, or prefix checks against `$REPO_ROOT`.

## Fix Focus Areas
- .claude/commands/generate-tests.md[18-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +115 to +129
For feature-gated variants, add the gate(s):

```yaml
# Single feature gate:
featureGate: <FeatureGateName>

# Multiple feature gates:
featureGates:
- <FeatureGate1>
- <FeatureGate2>

# Negative gates (enabled in ungated but not when this gate is active):
featureGates:
- -<FeatureGateName>
```

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Featuregate key ignored 🐞 Bug ✓ Correctness

The command instructs using featureGate: for single-gate variants, but the test suite loader only
reads featureGates (slice). Generated gated suites will be treated as ungated and run against all
CRD variants, causing incorrect coverage and potential false failures.
Agent Prompt
### Issue description
`/generate-tests` currently instructs generating `featureGate: <name>` for single-gated variants, but the test runner’s `SuiteSpec` only consumes `featureGates` (slice). As a result, single-gated suites generated from these instructions will be treated as ungated.

### Issue Context
The YAML loader unmarshals directly into `SuiteSpec` and filtering logic checks `len(featureGates)==0` to decide whether a suite is ungated.

### Fix Focus Areas
- .claude/commands/generate-tests.md[115-129]
- .claude/commands/generate-tests.md[392-394]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +70 to +104
Read the types file(s) and extract all information. Also read the corresponding CRD manifests
from `zz_generated.featuregated-crd-manifests/<plural>.<group>/` to get:
- The list of CRD variants (ungated, per-featureGate, compound)
- The full CRD name
- Default values applied by the schema
- The full OpenAPI v3 validation tree

## Step 3: Understand Existing Tests

Check the `tests/` directory for existing test suites:

```bash
# List existing test files for this CRD
TEST_DIR="$API_DIR/tests"
if [ -d "$TEST_DIR" ]; then
echo "=== Existing test directories ==="
ls -la "$TEST_DIR/"
fi
```

If test files already exist for this CRD, read them to understand existing coverage.
Do NOT duplicate tests that already exist. Only add tests for NEW or MODIFIED fields/types.

## Step 4: Generate Test Suites

For each CRD variant found in `zz_generated.featuregated-crd-manifests/<plural>.<group>/`,
generate a corresponding test file at:

```text
<group>/<version>/tests/<plural>.<group>/<VariantName>.yaml
```

Where `<VariantName>` matches the CRD manifest filename (e.g., `AAA_ungated.yaml`,
`OnPremDNSRecords.yaml`, `FeatureA+FeatureB.yaml`).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. Incorrect manifest/output paths 🐞 Bug ✓ Correctness

The command references zz_generated.featuregated-crd-manifests/<plural>.<group>/ and outputs to
<group>/<version>/tests/..., but in-repo featuregated manifests and suites are located under the
API directory (e.g., security/v1/zz_generated.featuregated-crd-manifests/... and
security/v1/tests/...). Following the doc literally can cause “not found” variant discovery and
tests written to paths the runner won’t load.
Agent Prompt
### Issue description
The command’s documented paths are ambiguous/wrong relative to this repo’s layout: featuregated CRD manifests and generated suites live under the specific API directory (like `security/v1/...`), not at repo root, and `<group>` is overloaded (API group domain vs directory name).

### Issue Context
Existing repo tooling (`tests/hack/gen-minimal-test.sh`) demonstrates the expected layout and will be what developers mirror.

### Fix Focus Areas
- .claude/commands/generate-tests.md[70-76]
- .claude/commands/generate-tests.md[93-104]
- .claude/commands/generate-tests.md[301-309]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 12, 2026

@chiragkyal: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@chiragkyal
Copy link
Member Author

Testing

Route v1 test generation

Exported on 13/02/2026 at 0:03:44 GMT+5:30 from Cursor (2.4.28)


User

/generate-tests routes/v1


Cursor

I'll generate tests for the routes/v1 API directory. Let me start by exploring the directory structure and understanding the types defined there.

Let me look at example test files from other APIs to understand the full test pattern better, and then I'll generate comprehensive tests.

Now I have a comprehensive understanding of the test format. Let me create comprehensive test files for the Route API. I'll update both the AAA_ungated.yaml and RouteExternalCertificate.yaml files with additional tests covering all validation rules.

Now let me update the RouteExternalCertificate.yaml with more comprehensive tests for that feature gate.

Now let me run the tests to verify they work correctly.

The tests require network access to start a local Kubernetes control plane. Let me verify the YAML syntax of the test files instead.

Let me verify the full content of the test files.

I have successfully generated comprehensive integration tests for the route/v1 API. Here's a summary of what was added:

Summary of Generated Tests

AAA_ungated.yaml (59 tests total)

Extended from the original tests with new test cases covering:

New Field Validation Tests:

  • Host field: Valid hosts, single-label hosts, invalid characters, hyphen prefix/suffix validation
  • Subdomain field: Valid subdomains, multi-part subdomains, invalid patterns
  • Path field: Valid paths, root path, paths without leading slash
  • to.kind: Service enum validation, empty kind default, invalid kind rejection
  • to.name: Empty name validation (MinLength=1)
  • to.weight: Boundary testing (0, 256), out-of-range values (257, -1)
  • alternateBackends: Max 3 backends, weight validation, empty name validation
  • wildcardPolicy: None, Subdomain, empty (default), invalid values
  • TLS termination: edge, reencrypt, passthrough, invalid types
  • insecureEdgeTerminationPolicy: Allow, Redirect, None, invalid values
  • Port: Integer and string targetPort support

Preserved Existing Tests:

  • TLS passthrough + insecureEdgeTerminationPolicy combinations
  • HTTP header actions validation
  • Reserved header restrictions (HSTS, Proxy, Cookie, Set-Cookie)
  • Dynamic header value format validation (HAProxy format strings)
  • Sample fetcher/converter restrictions for request/response headers

RouteExternalCertificate.yaml (12 tests total)

Extended from the original tests with new test cases for the RouteExternalCertificate feature gate:

  • Basic route creation (minimal Route)
  • TLS passthrough + insecureEdgeTerminationPolicy combinations
  • externalCertificate only (edge and reencrypt termination)
  • externalCertificate + destinationCACertificate
  • externalCertificate + caCertificate
  • Traditional certificate + key (no externalCertificate)
  • externalCertificate + insecureEdgeTerminationPolicy Redirect
  • Mutual exclusion: Cannot have both certificate and externalCertificate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants