The problem it solves
Browser tests are the tests most likely to rot. They are written once by a developer, break when the UI changes, and are quietly switched off. Paxter lowers the cost of writing and maintaining them by taking the test out of code: a workflow is a readable list of actions and data that a tester, analyst or developer can write and review.
What it does
- Workflows in YAML. Each workflow is a list of actions (navigate, click, type, assert) with the data they need, kept in the repository beside the application.
- Headless Chromium. Runs unattended in CI, or visibly on a developer's machine when you want to watch.
- Video capture. Switch on recording for a run and get a video of exactly what the browser did.
- Parallel runs and iterations. Run several workflows at once and repeat a workflow to shake out intermittent failures.
- HTML report. A summary of every workflow, step and result, opened automatically if you want.
A workflow
Headless: true
NeedVideo: false
Actions:
- Do: Page_GotoAsync
Data1: https://your-approved-test-environment.example
Where it came from
Paxter is the successor to Bromine, an earlier Booolean library that made Selenium page-object testing simpler. The lesson from Bromine was that the biggest cost was not the browser automation but the maintenance, so Paxter moved the test definition out of compiled code altogether.
Getting it
Paxter runs on Booolean engagements today and is licensed per organisation. If you would like to see it running against your application, get in touch.