Test Cases
A test case represents a single test scenario, like "User can add item to cart" or "Password reset sends email".
Creating a Test Case
- Navigate to a test suite
- Click New Test
- Choose a creation method:
- Generate from Video - Upload a screen recording
- Generate from Text - Describe the flow in words
- Create Manually - Add steps one by one
Test Case Structure
Each test case contains:
Test Case
├── Name → "User Login"
├── Description → Optional description
├── Steps
│ ├── Draft → Work-in-progress steps
│ └── Published → Steps used in CI/CD
└── Assertions → Verification conditions
Draft vs Published
Test cases maintain two versions of steps:
Draft Steps
- Editable in the UI
- Used when clicking "Run" in the editor
- Safe to experiment with
Published Steps
- Used in CI/CD pipeline runs
- Updated when you click "Publish"
- Stable version for automated runs
This separation lets you iterate on tests without breaking your CI/CD pipeline.
Test Case Status
| Status | Description |
|---|---|
| Draft | New test, not yet published |
| Active | Published and ready for CI/CD |
| Archived | Hidden from view, not executed |
Editing a Test Case
- Click on a test in the sidebar
- Edit the name, steps, or assertions
- Changes are auto-saved to draft
- Click Publish when ready
Publishing Changes
When you publish:
- Draft steps become published steps
- Draft assertions become published assertions
- CI/CD runs will use the new version
Skip Branches
Skip specific tests on certain Git branches:
- Open test settings
- Add branch names to "Skip Branches"
- Test won't run when triggered from those branches
Useful for:
- Skipping slow tests on feature branches
- Only running certain tests on
main
Deleting a Test Case
- Open the test
- Click the Delete button
- Confirm deletion
Deleted tests cannot be recovered. Consider archiving instead.
Best Practices
- One scenario per test - "Login" and "Logout" should be separate tests
- Descriptive names - "User can reset password via email" not "Test 1"
- Keep tests independent - Each test should work on its own
- Publish when stable - Don't publish untested changes
- Use assertions - Always verify the expected outcome