Sarvada Labs: BDD test automation frameworks
Two open-source (MIT) reference frameworks for UI and API testing
The starting point for every QA engagement we take on: a Cucumber 7 UI framework on Selenium 4 and a Cucumber 7 API framework on Rest Assured 6. Both run green in public CI, both are written to be handed over, and both are on GitHub for anyone to read before they hire us.
These are self-built, self-maintained frameworks published under our own name. They contain no client code and no client data. The demo suites run against public sandbox sites, not against any customer’s product.
Show the framework before selling the framework.
Every QA proposal promises a “maintainable automation framework.” Almost none of them let you read one before you sign. We think that is backwards, so ours are public: the architecture, the step vocabulary, the CI workflow and the README a client team would inherit are all on GitHub.
They also solve a practical problem. A new engagement should not start from an empty folder. Both frameworks give a project a working test layer on day one — page objects, parallel execution, reports, secrets handling and a pipeline — so the paid time goes into your flows, not into plumbing.
They began life years ago as internal frameworks written for enterprise identity and e-commerce testing. In 2026 they were rebuilt from scratch on current tooling, stripped of anything proprietary, and published.
One for the browser, one for the API.
sarvada-bdd-ui-framework
Java 21 · Cucumber 7 · Selenium 4 · TestNG · Maven
Plain-English Gherkin scenarios drive page objects; the page objects own every locator and every wait. Browsers are created per thread, so a suite runs sequentially or in parallel with one flag, locally or on a Selenium Grid, headed or headless, on Chrome, Edge, Firefox or Safari.
- Explicit waits only; clicks and typing verify their own effect and retry, which removes the usual sleep-based flakiness.
- Layered configuration: command-line flag, environment variable, local override, environment file, defaults. Secrets never touch the repository.
- Reports for every audience: rich HTML dashboard, JSON, JUnit XML for CI, a parallel-run timeline, and a rerun file for failures.
- Ships with a 10-scenario demo suite against a public sample store: login, catalogue sorting, cart and checkout.
sarvada-bdd-api-framework
Java 21 · Cucumber 7 · Rest Assured 6 · TestNG · Maven
A reusable Gherkin vocabulary for HTTP: build a request from named test data, send it to a named endpoint, assert on status, headers, JSON fields, list sizes and JSON Schema. No step definition knows a URL or a credential, so onboarding a new API is configuration plus feature files, not Java.
- Negative tests for free: one correct value yields INCORRECT, INVALID, NULL and EXPIRED variants automatically.
- Chained calls: save any response field and reuse it in later requests, or compare two endpoints’ responses against each other.
- Every request and response is logged with credential headers masked; the last response is attached to the report on failure.
- Ships with an 11-scenario demo suite against a public JSON API: CRUD, filtering, contract checks and error cases.
Readable by the product owner, executable by CI.
Feature files stay in the language of the business. The UI example below is the checkout flow from the demo suite; the API example creates a record, then reads its owner back and checks the two responses agree.
Because the steps are generic, the same vocabulary carries from project to project. A client team that reads one feature file can write the next one.
Scenario: Complete an order end to end
Given I am logged in as a standard user
And I add "Sauce Labs Fleece Jacket" to the cart
And I open the cart
And I proceed to checkout
When I enter customer details "Asha" "Verma" "302001"
Then the order total should be shown
When I finish the order
Then I should see the confirmation "Thank you for your order!"Scenario: Create a post, then read the author it belongs to
Given I set the request body to:
| userId | ${data:USER_ID} |
| title | Sarvada BDD ${random:string} |
When I send a POST request to "POSTS"
Then the response status code should be 201
And the response should match the schema "schemas/post.schema.json"
And I save the response field "userId" as "authorId"
Given I add "id" as "${saved:authorId}" in "PATH"
When I send a GET request to "USER_BY_ID"
Then the "POSTS" response field "userId"
should equal the "USER_BY_ID" response field "id"The choices that keep a suite alive after handover.
Thin steps, fat pages
Step definitions only translate Gherkin into page-object or client calls and assert the result. Locators, waits and HTTP details live in exactly one place, so a UI or API change is a one-file fix, not a hunt through the suite.
No shared mutable state
One browser per thread, one context object per scenario, no static fields. Parallel execution is a flag, not a refactor, and a failing scenario cannot poison its neighbours.
Secrets stay outside the repository
Configuration resolves from command-line flags, then environment variables, then a git-ignored local file, then per-environment files. Credentials arrive from CI secrets; logs mask authorization headers before they are written.
Zero driver management
Selenium Manager resolves the matching browser driver at run time. No binaries checked in, no third-party driver downloader, nothing to update when the browser does.
Continuous integration from the first commit
Both repositories run their suites on every push and pull request through GitHub Actions and publish the reports as build artifacts. A green badge on the repo means the demo suite passed today, not once.
Built to be given away
A client-facing README, a Maven wrapper so nothing needs installing beyond a JDK, and a layout a new engineer can navigate in an afternoon. The point of the framework is that you can keep it without us.
What the public repositories actually do.
These figures come from running the published demo suites on a developer laptop and in GitHub Actions. They describe the frameworks, not any client system.
10 scenarios
Login, catalogue, cart and checkout. Around ten seconds on four parallel browsers; passes on Chrome and Edge.
11 scenarios
CRUD, filtering, schema validation, chained requests and error cases. Under five seconds on four threads.
4
Chrome, Edge, Firefox and Safari, headed or headless, local or on a Selenium Grid.
Every push
GitHub Actions runs both suites and uploads HTML, JSON, JUnit and timeline reports as artifacts.
A head start, then your flows, then your repository.
Fork, configure, run
A QA engagement begins by pointing the framework at your environments: base URLs, endpoints and named test data. The demo scenarios are replaced, the plumbing stays.
Your highest-risk flows first
Scenarios are written for the paths that would cost you money if they broke, page objects and endpoints are added as needed, and the suite runs in your CI from the first week.
Handover, not dependency
The result lives in your repository under your name. Documentation and a walkthrough are part of the deliverable, so your team maintains it without a retainer.
Questions about the frameworks
Can we use these frameworks ourselves, without hiring Sarvada?
Yes. Both repositories are public on GitHub with a README covering setup, runtime switches, project layout and how to add a page or an endpoint. Clone one, run the Maven wrapper with a JDK 21 installed, and the demo suite runs. Both are released under the MIT licence, so you can use, modify and ship them commercially with attribution. There is no hosted service and nothing that phones home.
What does a client engagement built on them look like?
We fork the framework into your repository, point its configuration at your environments, and replace the demo scenarios with your critical flows. The suite runs in your CI within the first week. Engagements are fixed-scope and fixed-price; the QA landing page lists published starting prices.
Why Cucumber and Gherkin rather than plain JUnit or Playwright tests?
Because the scenario text is a shared artefact. Product owners can read and review it, developers can extend it, and the same vocabulary carries between projects. Where a client already standardises on another stack we work in that stack instead; the design principles on this page transfer.
Do the demo suites test a real client system?
No. The UI suite runs against a public sample store and the API suite against a public sandbox API, both chosen because they are free, stable and safe to hit from CI. No client code, data or credentials appear in either repository or its history.
How do you keep credentials out of the code?
Configuration resolves from command-line flags first, then environment variables, then a git-ignored local file, then per-environment property files. Secrets are supplied by the environment or CI secret store, and the API framework masks authorization headers, API keys, tokens and cookies before writing its request log.
Will the frameworks keep working as browsers and libraries update?
Browser drivers are resolved automatically at run time by Selenium Manager, so a browser update needs no change. Library versions are pinned in the Maven build and updated deliberately; the CI run on every push shows immediately if an update broke anything.
Want this running against your product?
The frameworks are the starting point. A QA engagement puts your highest-risk flows on top of them and hands the result to your team.