PrideForge — Automation solution & Academy

What is PrideForge?

PrideForge is a software product — a production-ready automation solution plus structured Academy training for organizations. It is not a tutorial on how to build an automation framework from scratch, personal coaching, freelance consulting, or a slide-deck-only course. You license the solution and seat-based Academy access for your QA/SDET team through Leonyx LLC.

The product comes first. You receive a complete, runnable PrideForge solution (features, steps, page objects, configs, fixtures, reporting). PrideForge Academy is the companion course that documents and teaches that solution — how to configure, extend, and run it for your applications.

PrideForge is not a new test automation product or vendor lock-in. It is an integrated solution — proven open-source components (Reqnroll, Playwright, NUnit, axe-core, and more) wired together with configuration, patterns, and runnable examples you can deploy on day one. Leonyx did not invent a replacement for Playwright; PrideForge is how those tools are organized to scale on real projects.

You do not start from an empty repository or a slide deck. You start from code that already runs: features, step definitions, page objects, environment configs, fixtures, and reporting. PrideForge Academy teaches you how to adapt that foundation — or how to strengthen your own stack using the same ideas.

Built on proven open-source tooling

PrideForge brings together modern open-source technologies into one cohesive automation solution — not a closed platform or a from-scratch tutorial on framework design. You keep standard tools your team can hire for and maintain; PrideForge is the integration layer, conventions, and reference implementation.

Reqnroll
Playwright
NUnit
axe-core

The goal is simple: help teams spend less time fighting automation infrastructure and more time improving software quality.

Solution + course — not course alone You are buying software, not just training. PrideForge Academy does not teach generic “how to write a framework.” It explains a specific, production-shaped automation solution you already have access to. If you only wanted a video course on framework theory, this is the wrong product.

Your framework, your choice You do not have to adopt PrideForge wholesale. Many teams purchase a license to study a reference implementation and take away proven patterns: shared BDD steps instead of per-control boilerplate, named locators, environment configs, field-handler dispatch, session reuse, table helpers, and reporting discipline. Use PrideForge as a starting point, cherry-pick patterns into your repo, or simply apply the lessons to refactor Selenium, Playwright, Cypress, or in-house code — the course explains why each pattern exists so you can map it to your tools and conventions.

Proven across complex domains

These patterns are not theoretical. They come from frameworks built and maintained in environments where reliability, auditability, and long-term maintenance matter.

Financial Institutions
Hospitality
Government
Home Mortgages
Fair Lending
Business Intelligence
Beverage Distribution
Tax Software

Who this is for

QA engineers, automation developers, and tech leads who are building a new framework, modernizing an existing one, or evaluating PrideForge against what they already run. You might adopt the reference solution end-to-end, port selected patterns into Selenium or Playwright code you own, or use the lessons as an architecture guide for your next refactor. Basic C# and Gherkin familiarity helps; we teach the reasoning behind each pattern, not only PrideForge syntax.

What you get

A site license includes the PrideForge automation solution (software you run in your environment) and PrideForge Academy (the course that explains it). The subscription term covers delivery services — repo access, Academy seats, updates, and support. The software and customizations you make during an active term remain yours to run internally after the term ends, per the EULA.

PrideForge automation solution

The licensed product — a production-shaped solution you clone, build, and run on day one.

Runnable Gherkin features and shared step vocabulary
Page objects, field handlers, and locator patterns
Multi-environment config, auth, tables, accessibility, reporting
Local fixtures for deterministic learning and CI

PrideForge Academy

The companion course — explains the solution and how to configure and extend it (not a generic framework tutorial).

Lessons mapped to runnable features in the licensed solution
When to extend handlers, steps, and server configs
How to map your pages, sitemaps, and test data

Patterns for your existing stack

Optional — transferable design knowledge if you cherry-pick into another codebase.

Reduce wrapper-method sprawl with generic steps + handlers
Structure environments, auth, and data for maintainability
Improve BDD adoption and cross-team readability
Architecture rationale from 20+ years of framework work

Patterns, not vertical templates Industry experience informs the architecture — not pre-built vertical packs PrideForge is not a bundle of mortgage-only or tax-only test templates. You receive transferable patterns proven across finance, government, hospitality, and more — then wire in your URLs, credentials, page objects, and compliance rules for your company.

Your solution keeps running when the subscription term ends If you do not renew, delivery services stop — Academy portal access, private repository access, new updates, and support. Under the EULA, your organization may continue to use the PrideForge software and any customizations you made during the active term, including running tests in CI, on your internal systems. Renewal restores delivery services and access to new versions.

Built on experience, not hype PrideForge is developed and maintained by a QA automation leader with more than 20 years of experience building test automation solutions across enterprise and regulated industries — including finance, government, hospitality, and high-volume commercial applications. See About Leonyx for who stands behind the product.

How PrideForge Academy supports the solution

The Academy is not a standalone framework course. Each lesson maps to a Features/*.feature file in the licensed PrideForge solution — you read the lesson, then work in the same code you run in CI.

45 guided classes — four learning paths: Writing Tests with PrideForge, Configuring and Extending PrideForge, Task guides & checklists, and Running PrideForge in CI/CD
Tailoring guide — extend handlers, configs, and conventions for your org
Hands-on features — open the matching Gherkin and fixtures in your IDE
Production patterns — auth sessions, reporting, CI filters, multi-environment servers

How licensing works

Purchase — buy a site license with author seats for your organization.
Assign — your license manager assigns seats to QA/SDET emails from the Company page.
Learn — assigned authors work through Academy lessons and apply patterns in the licensed framework.

Why PrideForge is better

Less boilerplate, clearer reports, and a full pattern library — browse the highlights below. PrideForge still uses Playwright and open-source tools; it organizes them so teams move faster with less framework code.

Why teams choose PrideForge

vs raw Playwright — scenarios stakeholders can read, not only scripts developers maintain.
vs record-and-playback — named locators and handlers survive UI refactors better than brittle recordings.
vs starting from scratch — teaching app, documentation, offline CI, and extension points ship together.

PrideForge packages proven patterns behind a consistent Gherkin vocabulary — so teams gain speed and structure without learning every implementation detail on day one. Use the tabs above to compare test style, data handling, framework core, training, and reporting and accessibility output side by side.

Test writing

PrideForge simplifies automation with Gherkin scenarios backed by reusable steps. You describe flows in plain language instead of repeating Playwright setup, URLs, and selectors in every test file. Interactions use simple patterns: When I set "PageName.Member" to "value" automatically determines how to interact with the element and set its value regardless of whether it is a text field, select, checkbox, or custom widget. Validations follow the same vocabulary: generic Then steps assert whether the element matches the expected criteria without bespoke assertion code in each scenario. The comparisons below show the same behaviors written two ways.

Example 1 — Login scenarios

Two login checks: imperative Playwright on the left, a few lines of Gherkin per scenario on the right.

Standard Playwright

Imperative script — every test repeats setup, URLs, selectors, and assertions.

 1import { test, expect } from '@playwright/test';
 2
 3const BASE_URL = 'http://localhost:8765';
 4const USER = 'admin';
 5const PASS = 'localpass123';
 6
 7test('admin login shows authenticated status',
 8  async ({ page }) => {
 9  await page.goto(`${BASE_URL}/login.html`);
10  await page
11    .getByLabel('Username')
12    .fill(USER);
13  await page
14    .getByLabel('Password')
15    .fill(PASS);
16  await page
17    .getByRole('button', { name: 'Sign in' })
18    .click();
19  await expect(
20    page.locator('#auth-status')
21  ).toContainText('Authenticated as admin');
22});
23
24// Next test? Copy-paste URL, waits, locators again…
25test('invalid login shows error',
26  async ({ page }) => {
27  await page.goto(`${BASE_URL}/login.html`);
28  await page.getByLabel('Username').fill('admin');
29  await page
30    .getByLabel('Password')
31    .fill('wrong-password');
32  await page
33    .getByRole('button', { name: 'Sign in' })
34    .click();
35  await expect(
36    page.locator('#login-error')
37  ).toBeVisible();
38});

LocalLogin.feature — Gherkin

PrideForge BDD

Readable specification — shared steps and named page objects, no duplicated boilerplate.

 1Feature: Local login
 2
 3  Scenario: Successful login with local admin user
 4    Given I login as "admin"
 5    Then The "LocalLoginPage.AuthStatus" field
 6      should contain "Authenticated as admin"
 7
 8  Scenario: Invalid credentials show an error
 9    Given I login as "invalid"
10    Then The "LocalLoginPage.LoginError" field
11      should contain "Invalid credentials"
12
13# Login, navigation, tables, a11y — same step vocabulary
14# Selectors live in page objects, not in every scenario

Example 2 — Interactions

One step for every control type — no helper method per widget and no C# wrapper per field.

widgets.spec.ts + helpers

Playwright — method per control type (or per field)

Tests pass human descriptions; you maintain helpers and/or one wrapper method per field.

 1// Option A: UI helper — one method per *kind* of control
 2async function setTextField(page, label, value) {
 3  await page.getByLabel(label).fill(value);
 4}
 5async function setNativeSelect(page, label, value) {
 6  await page.getByLabel(label).selectOption({ label: value });
 7}
 8async function setCheckbox(page, label, checked) {
 9  const box = page.getByLabel(label);
10  checked ? await box.check() : await box.uncheck();
11}
12
13test('fill widgets form', async ({ page }) => {
14  await page.goto('/widgets.html');
15  // Descriptions duplicated; break if UI copy changes
16  await setTextField(page, 'Display name', 'Widget User');
17  await setNativeSelect(page, 'Country', 'Canada');
18  await setCheckbox(page, 'Subscribe to updates', true);
19});
20
21// Option B: page object — one method per *field*
22class WidgetsPage {
23  setDisplayName(v) { return this.displayName.fill(v); }
24  setCountry(v) { return this.country.selectOption(v); }
25  setSubscribe(v) { return this.subscribe.setChecked(v); }
26  // + SetFruit(), SetActionMenu(), SetMudDate() …
27}

Widgets.feature — Gherkin

PrideForge — `I set "X" to "Y"`

One step for inputs; field handlers dispatch by element type. Locators live on the page object.

 1Feature: Widget and compound field handlers
 2
 3  Background:
 4    Given I open the widgets fixture
 5
 6  Scenario: Fill mixed controls with one step vocabulary
 7    When I set "WidgetsPage.DisplayName" to "Widget User"
 8    And I set "WidgetsPage.Country" to "Canada"
 9    And I set "WidgetsPage.SubscribeCheckbox" to "true"
10    And I set "WidgetsPage.FruitCombobox" to "Cherry"
11    Then The "WidgetsPage.DisplayName" field
12      should be "Widget User"
13
14# Page object defines WidgetsPage.DisplayName once
15# No SetDisplayName() C# per field — handlers already exist
16# New field? Add a property; reuse the same When step

Example 3 — Validations

Assert field rules and visibility with shared Then steps — not custom expect calls in every test.

validation.spec.ts — Playwright Test

Standard Playwright

Each rule is another locator and Playwright assertion in test code.

 1test('field rules on validation form',
 2  async ({ page }) => {
 3  await page.goto('/validation.html');
 4  await expect(
 5    page.getByLabel('Notes')
 6  ).toBeEditable();
 7  await expect(
 8    page.getByLabel('Notes')
 9  ).toHaveAttribute('maxlength', '500');
10  await expect(
11    page.locator('#readonly-banner')
12  ).toBeVisible();
13  await expect(
14    page.getByLabel('Locked field')
15  ).not.toBeEditable();
16});

Validation.feature — Gherkin

PrideForge BDD

Generic Then steps — page object members, not CSS or labels in the scenario.

 1Feature: Validation and presence
 2
 3  Scenario: Assert field rules without custom C#
 4    Given I open the validation fixture
 5    Then The "ValidationPage.Notes" field
 6      should be editable
 7    And The "ValidationPage.Notes" field
 8      should have maxlength "500"
 9    And The "ValidationPage.ReadOnlyBanner" field
10      should be visible
11    And The "ValidationPage.LockedField" field
12      should be readonly
13
14# InnerText, Contains, alerts — same step family
15# No new assertion helpers per form you test

Both use Playwright under the hood. PrideForge does not replace it — it organizes it. Gherkin scenarios stay short; engineers maintain step definitions and page objects once. New coverage is mostly new lines in .feature files, not new imperative scripts.

Locator handling

PrideForge keeps selectors out of scenarios. You name fields on page objects, reuse one step vocabulary, and let the framework resolve locators and choose the right interaction for each control type.

Locator resolve

Named PageName.Member locators with an ordered fallback chain so tests survive label and markup churn.

Element type handling

Field handlers route set, get, and click to the right interaction for each control type — without per-field test code.

Page object handling

Add page classes to your solution; the framework discovers and registers them — no manual wiring list to maintain.

Table handling

Search, select, paginate, and validate grids with shared steps — not a one-off helper per table in your app.

Custom widgets

Handlers for Mud, MUI, Quill, comboboxes, and menu buttons — register new types when your UI needs them.

Multiple application handling

Run the same framework against different applications, servers, and URLs without forking your step library. Configuration drives where tests execute and how auth and navigation behave per target.

Environments

Multi-server configuration, app vs server scoping, and guards so tests do not run unauthenticated by accident.

Auth handling

Smart vs forced login, saved sessions, and parallel-safe storage — spend less time re-authenticating every scenario.

Simplified login

One login step in Gherkin; application-specific UI stays behind a login registry you configure per product.

Simplified navigation

Sitemap-driven routes: jump by URL or walk menus using shared navigation steps tied to your environment config.

Data handling

Keep test data out of step code — resolve tokens at runtime and load structured data from files, tables, and stores. One vocabulary for literals in scenarios whether they come from expressions or external data.

Dynamic value resolving

Dates, variables, data-file paths, and values captured from the UI — resolved when steps run, not hardcoded in every test.

Data files & tables

JSON/CSV test data, persistent stores, Gherkin tables, and scenario outlines for data-heavy flows.

Framework core

The reference solution’s shape: plug-in registries, a single TestServices surface, parallel features, and a quality bar you can adopt in your own repo. Implementation details are covered in PrideForge Academy when you extend handlers and configs.

Extensible registries

Plug in pages, login flows, field handlers, file formats, and optional API or database integrations as your program grows.

TestServices

One service surface per scenario for locators, waits, interactions, and fields — less scattered helper code in steps.

Parallel runs

Feature-level parallelism with NUnit so suites finish faster without each test fighting for the same session files.

Quality baseline

258+ offline tests, cross-platform .NET 9, and headed or headless runs from configuration.

Training

PrideForge Academy is built for learning by doing — not slides alone. You work against a local teaching application, runnable Features/Local/ examples, and course classes that map to real patterns in the reference framework.

Sample pages & local demos

A built-in teaching application plus Features/Local/ examples so every pattern runs offline in CI — no live app required to start learning.

Teaching & CI

Offline CI (no network required), a live Sauce Demo reference, and intentional-failure demos that show how failures and reports look in practice.

Onboarding

Customization guides, “adding an application” walkthroughs, and a course-aligned local system under test so your team can adopt with a clear path.

Reporting: default Playwright vs PrideForge

Reporting beyond default Playwright

Rich HTML dashboards, failure screenshots, and optional traces — not only console lines and raw result files.

Playwright’s built-in output tells you what failed. PrideForge adds an ExtentReports HTML narrative — steps, media, and run context — so triage and sign-off take less digging.

playwright-report / CLI

12 passed

1 failed

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

Trace zip optional · screenshots manual · no scenario story

ExtentReports — PrideForge run

Run dashboard 45 scenarios · 98% pass · 2m 14s

LocalLogin.feature — Admin session PASSED
Given I login as "admin"
Then field should contain "Authenticated"
Screenshot attached
Widgets.feature — Mixed controls FAILED
When I set "WidgetsPage.Country" to "Canada"

Step timeline · failure screenshots · optional Playwright trace link

Accessibility: console output vs PrideForge report

Accessibility testing

axe-core scans from scenarios, with impact thresholds, known-issue allowances, and artifacts stakeholders can review.

Running axe is only half the story. PrideForge turns scan results into a gated, reviewable package — impact counts, known-issue exceptions, and artifacts for audit trails.

Typical axe CLI / assert

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

No screenshot · no suppression list · no release gate policy

PrideForge accessibility report

Checkout — accessibility scan Gate: FAILED

Critical0
Serious1
Moderate2
Known issues1 suppressed

Policy: 0 serious on release · HTML + JSON + screenshot artifacts

Solutions to Common Problems

Modern automation efforts often struggle with scalability, maintainability, collaboration, and long-term reliability. Many teams spend more time maintaining automation than benefiting from it. PrideForge addresses these patterns directly.

Fragile automation

Automation can become brittle as applications evolve, causing tests to fail frequently and creating ongoing maintenance overhead.

PrideForge helps teams build more resilient and maintainable automation workflows.

Framework sprawl

As automation grows, inconsistent patterns and duplicated logic can make frameworks difficult to manage and scale.

PrideForge provides a structured foundation designed to support long-term growth and consistency.

Slow onboarding

Many automation solutions require deep framework knowledge before contributors can become productive.

PrideForge simplifies common workflows and promotes shared standards that help teams ramp up faster.

Complex UI interactions

Modern applications often contain advanced UI components that are difficult to automate reliably using traditional approaches.

PrideForge is designed to support complex application behaviors through a unified automation architecture.

Environment inconsistency

Managing automation across multiple environments can introduce instability, duplication, and configuration complexity.

PrideForge streamlines environment management and execution workflows.

Limited team collaboration

Automation is often isolated to specialized engineers, limiting broader collaboration across QA, product, and development teams.

PrideForge promotes a more accessible and scalable automation approach that supports cross-functional contribution.

Difficult test data management

Hardcoded or inconsistent data strategies can reduce reliability and increase maintenance effort.

PrideForge helps teams create cleaner, more reusable automation workflows.

Authentication and session challenges

Repeated authentication workflows can slow execution and introduce instability into automated testing.

PrideForge includes streamlined approaches to support efficient and reliable execution flows.

Limited visibility and reporting

Many teams struggle to quickly diagnose failures or gain actionable insights from automation results.

PrideForge improves visibility into automation execution and quality workflows.

Accessibility as an afterthought

Accessibility validation is often disconnected from standard automation practices.

PrideForge helps integrate accessibility into broader quality workflows.

About Leonyx

Leonyx LLC develops practical software quality solutions focused on helping teams deliver reliable software faster. Our first product, PrideForge, combines a production-ready automation framework with structured training designed to accelerate automation adoption and reduce maintenance overhead.

PrideForge is built and maintained by Brandon Bruce, a QA leader and automation engineer with more than 20 years of experience building automation solutions across enterprise software organizations — including regulated industries, public-sector systems, and complex commercial applications.

A product company, not a coaching practice PrideForge is licensed software plus Academy access — sold with clear seat limits, renewal terms, and an End User License Agreement. You are buying a repeatable product your organization can deploy and assign to authors, not hourly coaching or custom project work.

Support

Support is provided directly by the creator of the framework — not a ticket queue or outsourced help desk. For licensing, seat assignment, or product questions, contact support@prideforge.com.

Brandon Bruce on LinkedIn

Legal entity

PrideForge Academy and site licenses are offered by Leonyx LLC (Florida). See the End User License Agreement and license summary for terms that apply at purchase.

Stop Building Automation Frameworks. Start Writing Tests. A production-ready automation solution for QA teams

How the solution fits together

What is PrideForge?

Built on proven open-source tooling

Proven across complex domains

Who this is for

What you get

PrideForge automation solution

PrideForge Academy

Patterns for your existing stack

How PrideForge Academy supports the solution

How licensing works

Why PrideForge is better

Test writing

Example 1 — Login scenarios

Standard Playwright

PrideForge BDD

Example 2 — Interactions

Playwright — method per control type (or per field)

PrideForge — I set "X" to "Y"

Example 3 — Validations

Standard Playwright

PrideForge BDD

Locator handling

Locator resolve

Element type handling

Page object handling

Table handling

Custom widgets

Multiple application handling

Environments

Auth handling

Simplified login

Simplified navigation

Data handling

Dynamic value resolving

Data files & tables

Framework core

Extensible registries

TestServices

Parallel runs

Quality baseline

Training

Sample pages & local demos

Teaching & CI

Onboarding

Reporting: default Playwright vs PrideForge

Reporting beyond default Playwright

Accessibility: console output vs PrideForge report

Accessibility testing

Solutions to Common Problems

Fragile automation

Framework sprawl

Slow onboarding

Complex UI interactions

Environment inconsistency

Limited team collaboration

Difficult test data management

Authentication and session challenges

Limited visibility and reporting

Accessibility as an afterthought

About Leonyx

Support

Legal entity

PrideForge — `I set "X" to "Y"`