#Shared Steps Best Practices
Shared Steps are a powerful abstraction in Hawzu. Used correctly, they dramatically reduce duplication and improve consistency. Used poorly, they can introduce hidden coupling across test cases.
This guide helps you strike the right balance.
#Use Shared Steps for Stable, Reusable Logic
Shared steps work best for behavior that rarely changes.
Good candidates:
- Login flows
- Common navigation steps
- Environment setup actions
- Reusable API calls
- Authentication or authorization checks
Avoid using shared steps for:
- Highly experimental flows
- One-off test logic
- Steps that change every sprint
Rule of thumb
If you expect to reuse a step in 3+ test cases, consider a shared step.
#Prefer Workspace Shared Steps for Organization-Wide Standards
Workspace shared steps are:
- Automatically available in all projects
- Ideal for enforcing organization-wide consistency
Use workspace shared steps for:
- Global login or onboarding flows
- Compliance or security checks
- Shared infrastructure validations
Use project shared steps when:
- Logic is project-specific
- Behavior differs across products
- Teams need freedom to evolve independently
#Keep Shared Steps Small and Focused
A shared step should do one thing well.
Bad example:
- “User completes full checkout flow”
Good examples:
- “User adds item to cart”
- “User enters payment details”
- “User confirms order”
Smaller steps:
- Are easier to reuse
- Reduce blast radius when changes happen
- Make failures easier to diagnose
#Write Clear Names and Descriptions
Shared steps are consumed across many test cases—clarity matters.
Best practices:
- Use action-oriented names
“User logs in with valid credentials”
- Avoid vague names
“Login step”
- Add descriptions explaining when the step should be used
Good naming reduces misuse and surprises.
#Treat Changes to Shared Steps as Breaking Changes
Editing a shared step affects all test cases using it.
Before updating:
- Check where the step is used
- Confirm the change is backward-compatible
- Communicate changes to the team if needed
For risky changes:
- Create a new shared step
- Migrate test cases gradually
- Deprecate the old step later
#Use Parameters Inside Shared Steps
Combine shared steps with parameters for flexibility.
Example:
- Shared step: “Open application URL”
- Parameter:
$APPLICATION_URL
This allows:
- Environment-specific execution
- Reuse across projects and releases
- Cleaner, more adaptable steps
#Be Careful When Deleting Shared Steps
Hawzu provides safe deletion options for a reason.
When deleting a shared step:
- Remove from usages if the step is obsolete
- Convert to regular steps if test cases still need the logic
Never delete blindly—always review impacted test cases.
#Avoid Over-Sharing
Not everything needs to be shared.
If a step:
- Is only used once
- Is tightly coupled to a specific test case
- Is rapidly evolving
Keep it local.
Shared steps should reduce complexity, not add indirection.
#Periodically Review Shared Steps
Over time, shared libraries grow.
Best practices:
- Review unused shared steps
- Consolidate similar steps
- Remove outdated logic
- Align naming conventions
Treat shared steps like code—they need maintenance.
#Think of Shared Steps as Infrastructure
The best mindset:
Shared steps are infrastructure, not shortcuts.
Design them with:
- Stability
- Clarity
- Reusability
- Long-term ownership
When done right, shared steps become one of Hawzu’s biggest leverage points.
#Next Steps