This is a full-blown test framework containing some sample tests that I engineered using TypeScript and Playwright as a take-home task for Five Sigma Finances.
- Support for Chromium (Chrome), Nightly (FireFox), Webkit (Safari)
- Playwright test report generation
- Test parallelization
- Failure screenshots
- Logging
- Integration with a demo CI/Adhoc/Nightly pipeline (Github Actions)
- Easy to modify CI/Dev configuration files
- Scalable POM implementation
- Custom test wrapper
- Dorny test reports built straight into Github (See known isssues)
This project requires Node.js v18+ to run.
Install the required dependencies.
npm iNext you need to install the Playwright browsers.
NOTE: For Linux, include --with-deps at the end of the command
npx playwright installRun the tests.
npm testThe main test configurations are split into two different files that can be located within src/config
| File | Description |
|---|---|
| test.config.ci.ts | The configuration that a CI environment will use |
| test.config.dev.ts | The configuration that your local development environment will use |
This seems to be some sort of logic error on my part where I did not account for something correctly when navigating through the calender. I will be fixing this later today.
FIXED: I missed some expected behaviour that involved the calender automatically switching to the previous month if "This Week" or "Last 7 Days" started in the previous month. This then caused the test to click the 'Back' navigation button again causing the calender to move 2 months instead of 1.
Sometimes Playwright fails to take a failure screenshot due to a race condition between the error being thrown and the page/browser context teardown. The easiest and most ideal solution for this would be to handle screenshots on failure manually by using the built in screenshot method within the Run Test method.
FIXED: A Playwright race condition where manually killing pages doesn't wait for the screenshots to occour. It was redundant for me to do it anyway as BrowserContext.close() kills the pages anyway.
Commented out for now, for some reason the https://mui.com/x/react-date-pickers/ website doesn't update the day properly, this is most likely due to how the website triggers an update for checking todays date. Needs more investigating into the actual website itself.
For some reason the built-in Dorny test report is only visible on runs that were triggered by a push/have a commit attached to them. When a run is scheduled or manually triggered, the 'Publish Dorny Test Report' step executes successfully but no Dorny test report is visible, instead the Dorny test report is shown on the last run that has a commit attatched to it. For now, there are Playwright reports uploaded as artifacts that can be viewed. Alternatively the Dorny Test Report can actually still be viewed by clicking on the 'Check run HTML' link under the executed step.
Annoyingly this seems to be an actual bug in dorny test reporter due to some Github limitations: dorny/test-reporter#550
Most likely worth looking for a different built-in test reporter without this issue or to just scrap having a built in test-reporter and relying on the Playwright reports themselves.
I'd like to implement some more functionality such as:
- Optimizing Pipelines
- Currently when the pipeline runs against each browser, each browser gets its own Ubuntu Environment. This means it has to build the project and complete setup for each browser which is not optimal. Currently I have implemented an optimization that only installs the browser that is needed rather than all of them, however, this could be optimized further by caching the dependencies during a setup job before any tests run. This would then allow the 'Run Tests' jobs to just use the cached dependency files instead, which would be faster and more optimal.
- Recycled Browser Contexts
- Having each test spin up its own Browser Context is fine, however if you really want to cut down test times, a great way to do this is by recycling Browser Contexts. This means each thread always only has a single Browser Context that stays alive until the thread finishes running all tests. This reduces the time taken to setup/create/teardown Browser Contexts between each test, although it adds a complexity especially once you start introducing multi-participant tests.
- Failure videos
- Playwright actually natively already supports failure videos, so this would be fairly easy to implement, however if I was to implement 'Recycled Browser Contexts', it would not be easy to implement due to how playwright handles failure videos and it would require me to implement custom functionality to achieve failure videos. This is because if you recycle Browser Contexts, Playwright will record all the tests that run within that Browser Context as one video rather than seperate ones.
© 2025 - 2025 Chris Wells - All Rights Reserved.