105 lines
3.5 KiB
Markdown
105 lines
3.5 KiB
Markdown
---
|
|
description: Write and validate new OpenShift E2E tests using Ginkgo framework
|
|
argument-hint: [test-specification]
|
|
---
|
|
|
|
## 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
|