Scalability & Maintainability
Large Robot suites fail for predictable reasons: wall-clock time, merge contention, and unclear ownership. Treat the framework like application code: boundaries, reuse, and measurable CI budgets.
Scalability challenges
| Challenge |
Typical signal |
Why it hurts |
| Large suites (1000+ tests) |
Long feedback loops, noisy reports |
Hard to bisect regressions; teams skip runs |
| Long execution times |
Pipelines miss merge windows |
“Merge queue” stalls; flaky retries multiply cost |
| Team collaboration |
Overlapping edits, duplicate keywords |
Drift, conflicting patterns, review fatigue |
Scalability solutions
Parallelization with Pabot
Shard suites or tests across processes; tune for CPU and shared resources (Pabot, parallel docs).
# Suite-level split (default): good when suites are independent
pabot --processes 4 tests/
# Finer grain when a few huge suites dominate runtime
pabot --processes 8 --testlevelsplit tests/checkout/
Use PabotLib when processes share databases, feature flags, or license seats—coordinate “run once” setup and exclusive resource pools.
Splitting by domain or team
| Approach |
Layout example |
Run command sketch |
| Repo folders per bounded context |
tests/orders/, tests/billing/ |
robot --include orders tests/orders |
| Separate CI jobs per folder |
Same + job matrix |
Parallel jobs, aggregated report in parent |
Owned resources/ per team |
resources/orders/orders.resource |
Import only what the suite needs |
Tag-based targeted runs
*** Test Cases ***
Smoke Checkout Happy Path
[Tags] smoke checkout critical
Given Cart With Single Item
When User Completes Checkout
Then Order Confirmation Is Visible
robot --include smoke --exclude wip tests/
robot -i "criticalANDcheckout" tests/
Contract testing and service isolation
| Pattern |
Robot’s role |
Notes |
| Consumer-driven contracts |
HTTP keywords hit mock/stub of provider |
Keep contracts in version control; fail CI on drift |
| Provider verification |
Dedicated job runs contract suite against provider build |
Isolate from full E2E |
| Service isolation |
Start dependencies via containers or test doubles |
Reduces flake vs shared staging |
Maintainability practices
- DRY: Shared flows live in
resources/ and Python libraries; .robot files orchestrate.
- Refactor like prod: Extract keywords when duplication appears; rename for domain language.
- Central locators/endpoints: One variables file or page resource per surface; no scattered URLs.
- Version-controlled test data: Fixtures in Git or generated in setup; secrets from CI secrets store.
- Review test code: Same checklist as app PRs (readability, data boundaries, failure messages).
Thin orchestration example
*** Settings ***
Resource ../resources/checkout_service.resource
*** Test Cases ***
Order Is Created Via API
${order_id}= Create Order With Payload ${VALID_ORDER}
Order Should Exist ${order_id}
Real-world architecture patterns
| System style |
Guiding principle |
Robot emphasis |
| API-heavy |
Thick API coverage, thin UI |
Libraries wrapping REST/GraphQL; UI only for critical journeys |
| Microservices |
Contracts + isolation |
Pact or schema checks; stub downstream in service-level suites |
| Full-stack |
API-first, then selective UI |
Layered resources; tags for e2e vs api |
Architecture decision table
| Decision |
Prefer when |
Trade-off |
| Pabot suite split |
Many small files, few shared fixtures |
Less granular than test-level split |
| Pabot test split |
Few huge suites |
Higher coordination cost; watch shared state |
| Dedicated contract job |
Many services, fast PR feedback |
Extra pipeline maintenance |
| Staging E2E (tagged) |
Revenue-critical UI |
Slower, flakier—keep count small |
Best practices summary
- Measure suite duration and flake rate before optimizing.
- Parallelize with clear data isolation; use PabotLib for shared scarce resources.
- Slice execution with tags and folder ownership.
- Push logic down into keywords and Python libraries; keep scenarios readable.
- Align depth with system architecture—API-first unless UI risk dominates.