Run a feature test in your project ->
Feature-Based Testing in BYOB: Test One Capability Deeply
BYOB testing now supports two scopes.
- Full-site testing for broad release confidence.
- Feature-based testing for deep validation of one workflow.
If your highest risk is login, checkout, onboarding, or payment flow, feature mode usually gives better signal faster.
TLDR
- Use feature mode for one critical flow at a time.
- Write a specific feature name before run.
- Include browser checks for UI-heavy workflows.
- Use history to compare regressions across sessions.
Scope selection logic
Why feature mode exists
Full-site tests are broad but can hide localized failure details in noise. Feature mode narrows context and spends test budget where risk is highest.
That gives better debugging speed.
- Less time parsing irrelevant checks.
- Clearer failure attribution.
- Faster rerun loops.
How to define feature scope properly
Bad scope examples.
authdashboard
Better scope examples.
magic-link login with expired token handlingcheckout with coupon + failed payment recovery
Precision in scope creates precision in report output.
Feature name should include trigger, expected path, and failure fallback path.
Suggested test run template
Use this input template for consistent runs.
- Feature name.
- Expected success condition.
- Known edge condition.
- Include visual pass yes or no.
- Include unit generation yes or no.
Full-site vs feature-based comparison
| Dimension | Full-site | Feature-based |
|---|---|---|
| Breadth | High | Focused |
| Depth per flow | Medium | High |
| Runtime | Longer | Usually shorter |
| Best use | Pre-release sweep | Regression and critical path validation |
Report interpretation guide
Feature reports should answer three questions.
- Does the primary path pass?
- Do edge conditions fail safely?
- Did performance or rendering regress?
If one fails, patch only the impacted slice and rerun feature mode first.
Use history as regression memory
BYOB stores prior runs so you can compare trend.
When a flow passed yesterday and fails today, compare commit range and isolate the smallest change set.
Release rhythm recommendation
- During development: run feature mode on each risky change.
- Before release: run one full-site sweep.
- After release hotfix: rerun feature mode on the patched flow.
This gives strong confidence without bloating test cycle time.
Common mistakes
Mistake 1: using feature mode with vague names
Vague scope creates vague checks and weaker signal.
Mistake 2: skipping edge conditions
Most regressions appear in fallback or retry paths, not happy path.
Mistake 3: treating one pass as permanent proof
Use repeated runs across versions. Trend matters more than one green report.
Triage workflow after a failed feature run
- classify failure as product logic, UI behavior, or setup bridge issue.
- isolate smallest related change since last passing run.
- patch that scope only.
- rerun same feature test before broad sweeps.
This keeps iteration tight and avoids large speculative rewrites.
Test artifact retention practice
For release-critical features, keep these records in sprint notes.
- last passing report ID
- latest failing report ID
- patch commit that restored pass
This audit trail helps during incident review and release retrospectives.
FAQ
Does feature mode replace full-site mode?
No. It complements it.
Should I always enable unit test generation?
Enable it when logic or data transforms changed. For pure copy edits, usually no.
Can I run feature mode on free plan?
Plan limits apply. Paid tiers unlock broader testing usage.
How often should I rerun same feature test?
Rerun after every meaningful change to that feature and before release.
