Product

Test authors write human-readable scenarios to script behavior without writing the underlying code. Engineers write code for application-specific needs without reinventing the plumbing. PrideForge handles the rest.

From Gherkin to browser

Each scenario says what was done and what was validated. The same words drive the browser through shared steps and page objects.

Handler priority

Built-in steps set and read common controls and widgets. When a control is unique to your application, you add a handler and choose where it runs. More specific handlers are tried first.

Targeted runs with tags

Once the scenario is written, choose which ones run. Tag features and scenarios with @env, @smoke, or your own labels. Then filter what executes locally or in CI without rewriting scenarios.

Working automation foundation

Under that run is the same foundation. PrideForge is built on Playwright, playwright-bdd, TypeScript, and axe-core. Scenarios stay as written while page objects and the framework absorb UI and environment changes.

PrideForge saves your team from building the framework and makes writing tests faster. Authors focus on the behaviors they want to test. Engineers handle application-specific implementation. Coverage scales without every test waiting on an engineer.

The same language works as living documentation for reviewers and in run reports: stakeholders see which business steps passed or failed, not source lines.

Playwright vs PrideForge test comparison

playwright-order.spec.ts

 1import { test } from '@playwright/test';
 2import { LoginPage } from '../pages/LoginPage';
 3import { OrdersPage } from '../pages/OrdersPage';
 4
 5const orders = [
 6  { customer: 'Acme Corp', type: 'Standard', priority: 'High', expedited: true, days: 7 },
 7  { customer: 'Wayne Supply', type: 'Custom', priority: 'Normal', expedited: false, days: 14 }
 8];
 9
10test.describe('Order Management', () => {
11  let ordersPage: OrdersPage;
12
13  test.beforeEach(async ({ page }) => {
14    await new LoginPage(page).login(
15      process.env.TEST_USER!,
16      process.env.TEST_PASSWORD!
17    );
18    ordersPage = new OrdersPage(page);
19    await ordersPage.goto();
20  });
21
22  for (const order of orders) {
23    test(`Create and update ${order.customer}`, async () => {
24      // Create order
25      await ordersPage.setCustomerName(order.customer);
26      await ordersPage.setOrderType(order.type);
27      await ordersPage.setPriority(order.priority);
28      await ordersPage.setExpedited(order.expedited);
29      await ordersPage.setDeliveryDate(`today+${order.days}`);
30      await ordersPage.createOrder();
31
32      // Verify new order
33      const row = ordersPage.findRow('Customer', order.customer);
34      await ordersPage.verifyGridRow(row, {
35        Customer: order.customer,
36        Type: order.type,
37        Priority: order.priority,
38        Expedited: order.expedited
39      });
40
41      // Update grid fields
42      await ordersPage.setGridDropdown(row, 'Priority', 'Critical');
43      await ordersPage.setGridCheckbox(row, 'Expedited', true);
44
45      // Verify updates
46      await ordersPage.verifyGridRow(row, {
47        Priority: 'Critical',
48        Expedited: true
49      });
50    });
51  }
52});

prideforge-order.feature

 1@Smoke
 2Feature: Order Management
 3
 4  Background:
 5    Given I am logged in as "admin"
 6    And I am on the "Orders" page
 7
 8  Scenario Outline: Create and update an order
 9    When I set "Customer Name" to "<Customer>"
10    And I set "Order Type" to "<Type>"
11    And I set "Priority" to "<Priority>"
12    And I set "Expedited" to "<Expedited>"
13    And I set "Delivery Date" to "<DeliveryDate>"
14    And I click "Create Order"
15
16    Then the "Orders" grid should contain a row where
17      | Customer   | Type   | Priority   | Expedited   |
18      | <Customer> | <Type> | <Priority> | <Expedited> |
19
20    When I find the row in the "Orders" grid where "Customer" is "<Customer>"
21    And I set "Priority" in that row to "Critical"
22    And I set "Expedited" in that row to "true"
23
24    Then that row should contain
25      | Priority | Expedited |
26      | Critical | true      |
27
28    Examples:
29      | Customer     | Type     | Priority | Expedited | DeliveryDate |
30      | Acme Corp    | Standard | High     | true      | {today+7}    |
31      | Wayne Supply | Custom   | Normal   | false     | {today+14}   |

Both use the same browser automation stack under the hood. PrideForge organizes it — Gherkin scenarios stay short and self-describing; engineers maintain step definitions and page objects once. Deeper examples ship with the licensed solution and Academy.

Named locators

You define the element on a page object and you can reference it in any scenario by using its name.

A page object defines OrderPage.Customer, a feature file uses that name, and the step resolves to the Customer Name field

Fields, grids, and custom widgets

One phrase sets a text box, a dropdown, or a checkbox. Shared steps find a grid row and change its cells. When a control is unique to your application, you add a handler.

Same scenario, different server

The scenario stays the same and you can choose the server when you run it. The URLs, users and navigation belong to that server, so the same test can run on staging or production.

Different applications stay in one framework

A server can point at a completely different application. You still say who is logged in. That server supplies the login, even when the process is nothing like the others.

Values filled in at run time

You put a placeholder in the step. PrideForge fills in the date, a saved value or a value from your data when the scenario runs.

One scenario, many rows

You keep the rows in a table or a file. The same scenario runs once for each row.

Reports show pass/fail with scenario steps, screenshots, and diagnostics — so failures triage without raw logs alone. Gherkin carries the same language into reports: stakeholders see which business steps passed or failed, not source lines.

test runner / CLI

12 passed

1 failed

login.spec.ts:45
Timeout 30000ms waiting for locator('#submit')
  at login.spec.ts:45:12

Counts and stack traces · no scenario steps · screenshots not automatic

ExtentReports showing a passed login feature, a failed widgets scenario with the failing step highlighted, and a screenshot attached on failure — Passing feature · failing step in the scenario timeline · screenshot attached for triage

Accessibility testing is built in, supported, and configurable. Lets your team run axe-core scans from Gherkin scenarios and produce reviewable pass-or-fail artifacts for release gates — not console dumps alone.

Typical axe CLI / assert

3 violations found
  serious: 2
  moderate: 1
#color-contrast (serious)
#aria-hidden-focus (serious)

Console output only · no gate policy · no scenario context or screenshots

PrideForge accessibility report

Checkout — accessibility scan Gate: FAILED

Critical0
Serious1
Moderate2
Known issues1 suppressed

Impact summary · release gate · known-issue list · HTML + JSON + screenshots

Learn the framework by running the framework. Every Academy lesson maps to examples in your installed PrideForge environment. Read the concept, run the scenario, inspect the implementation, then apply the same pattern to your application.

The Academy is hands-on onboarding and reference material included with licensed seats — built entirely around the framework you license. It teaches your team how to run, configure, and extend PrideForge so knowledge is not trapped with whoever built the automation first.

PrideForge Academy dashboard with learning paths and progress tracking — Academy dashboard — learning paths and progress

Academy lesson page with course navigation and an embedded Gherkin feature file — Lesson page — navigation plus the mapped sample feature

Offline teaching fixture Widgets page with country select and form controls — Local teaching fixture — practice without a live application

ExtentReports view with passed and failed scenarios and failure screenshot — Running samples — pass, fail, and screenshot on failure

Learn by running samples Every major capability has examples you can execute. Offline teaching fixtures run without a live app — start locally from your IDE, then move to your environments when you are ready. Intentional-failure demos show how reports and accessibility gates look when something breaks.

Local teaching fixtures

Deterministic sample pages for primitives, widgets, tables, validation, and more — paired with runnable scenarios so you can modify and learn each pattern hands-on.

Lesson ↔ sample mapping

Academy classes point at specific features and page objects in the licensed solution. Read the concept, run the sample, then apply the same steps to your application’s pages and configs.

Offline and reference runs

Samples pass deterministically without network access. Optional reference features show live-app patterns; local fixtures keep onboarding fast and repeatable for every User.

Configuration & extension guides

Walkthroughs for servers, login, sitemaps, handlers, and adding your own applications — so learners know when to extend the framework versus reuse existing steps.

Five learning paths

45 guided classes organized into paths that mirror how teams adopt PrideForge — from first scenarios through configuration, task checklists, and CI/CD.

Role-based learning paths
Getting Started — roles, install, and a first local run
Automation Author — Gherkin, shared steps, local fixtures, widgets, tables, validation
Platform Specialist — servers, environments, users, login handlers, and sitemaps
Framework Engineer — architecture, TestServices, handlers, registries, and extension
Operational guides
Task guides & checklists — numbered procedures when you need a fast how-to
CI/CD — filters, tags, GitHub Actions, Azure DevOps, Jenkins

How it works

From Gherkin to browser

Handler priority

Targeted runs with tags

Working automation foundation

Test writing

Playwright vs PrideForge test comparison

Locator resolution

Named locators

Fields, grids, and custom widgets

Multiple applications

Same scenario, different server

Different applications stay in one framework

Data handling

Values filled in at run time

One scenario, many rows

Reporting

Accessibility

PrideForge Academy

Local teaching fixtures

Lesson ↔ sample mapping

Offline and reference runs

Configuration & extension guides

Five learning paths