/new-e2e-test

Name

openshift:new-e2e-test

Synopsis

/new-e2e-test [test-specification]

Description

The new-e2e-test command assists in writing and validating new tests for the OpenShift test suite. It follows best practices for Ginkgo-based testing and ensures test reliability through automated validation.

This command handles the complete lifecycle of test development:

• Writes tests following Ginkgo patterns and OpenShift conventions
• Validates tests for reliability through multiple test runs
• Ensures proper test naming and structure
• Handles both origin repository and extension tests appropriately

Test Framework Guidelines

Ginkgo Framework

• OpenShift-tests uses Ginkgo as its testing framework
• Tests are organized in a BDD (Behavior-Driven Development) style with Describe/Context/It blocks
• All tests should follow Ginkgo patterns and conventions except
  • You MUST NOT use BeforeAll, AfterAll hooks
  • MUST NOT use ginkgo.Serial, instead use the [Serial] annotation in the test name if non-parallel execution is required

Repository-Specific Guidelines

Origin Repository Tests

If working in the "origin" code repository:

• All tests should go into the test/extended directory
• If creating a new package, import it into test/extended/include.go
• After writing your test, MUST rebuild the openshift-tests binary using make openshift-tests

Other repositories

Other repositories have have different conventions for locations of tests and how they get imported. Examine the code base and follow the conventions defined.

Critical Test Requirements

Test Names

CRITICAL: Test names must be stable and deterministic.

❌ NEVER Include Dynamic Information:

• Pod names (e.g., "test-pod-abc123")
• Timestamps
• Random UUIDs or generated identifiers
• Node names
• Namespace names with random suffixes
• Limits that may change later

✅ ALWAYS Use Descriptive, Static Names:

• Good example: "should create a pod with custom security context"

• Bad example: "should create pod test-pod-xyz123 with custom security context"

• Good example: "should create a pod within a reasonable timeframe"

• Bad example: "should create a pod within 15 seconds"

Results

CRITICAL: Tests must always produce a pass, fail or skip result. Do not create tests that only produce pass or only produce a fail result.

Test Structure Guidelines

Best Practices

• Tests should be focused and test one specific behavior
• Use proper setup and cleanup in BeforeEach/AfterEach blocks
• Include appropriate timeouts for operations
• Add meaningful assertions with clear failure messages
• Follow existing patterns in the codebase for consistency

Implementation

The command performs the following steps:

1. Analyze Specification: Parse the test specification provided by the user
2. Write Test: Create a new test file following Ginkgo and OpenShift conventions
   • Determine correct location
   • Follow proper test structure
   • Use stable, descriptive naming
   • Implement proper setup/cleanup
3. Build Binary: Rebuild the appropriate test binary (openshift-tests or a test extension)

Arguments

• $1 (test-specification): Description of the test behavior to validate. Should clearly specify:
  • What feature/behavior to test
  • Expected outcomes
  • Any specific conditions or configurations