PrideForge Academy — Leonyx automation training

What is PrideForge?

PrideForge is not a proprietary test product or vendor lock-in. It is a working base framework — a complete, runnable solution on Reqnroll, Playwright, and NUnit — combined with patterns proven across real enterprise automation programs.

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 a unified automation solution focused on scalability, maintainability, and acceleration — not a closed platform you have to learn from scratch.

Reqnroll
Playwright
NUnit
axe-core

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

Your framework, your choice You do not have to adopt PrideForge wholesale Many teams enroll 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 modules 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

Working base framework

A production-shaped PrideForge solution you can 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

Training to tailor PrideForge

Step-by-step lessons on extending and configuring the reference solution.

When to extend handlers, steps, and server configs
How to map your pages, sitemaps, and test data
Runnable examples for every major pattern

Concepts for your existing framework

Transferable design knowledge — not “replace everything or leave.”

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.

Built on experience, not hype PrideForge reflects more than 20 years of industry experience designing, building, and maintaining automation frameworks from the ground up — across regulated industries, public-sector systems, and high-volume commercial applications.

What you will learn in PrideForge Academy

Each lesson maps to a Features/*.feature file in the working PrideForge solution. You learn the concepts here, then apply them while tailoring page objects, environments, and data to your company’s systems.

24 guided modules — Basic, Intermediate, and Expert tracks from install through advanced framework topics
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 enrollment works

Purchase — unlock PrideForge Academy for your organization.
Log in — use your checkout email and student password.
Learn — work through lessons in order or jump to the topic you need.

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 modules 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.

Master your automation with PrideForge A proven automation solution The tools you know, Organized to scale

What is PrideForge?

Built on proven open-source tooling

Proven across complex domains

Who this is for

What you get

Working base framework

Training to tailor PrideForge

Concepts for your existing framework

What you will learn in PrideForge Academy

How enrollment 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

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