3.5 KiB
description, argument-hint
| description | argument-hint | |
|---|---|---|
| Write and validate new OpenShift E2E tests using Ginkgo framework |
|
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/extendeddirectory - 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:
- Analyze Specification: Parse the test specification provided by the user
- 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
- 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