Playwright-BDD - https://vitalets.github.io/playwright-bdd/#/
Playwright Test - https://github.com/microsoft/playwright
http server - https://www.npmjs.com/package/http-server
git clone https://github.com/JohnRudden/playwright_assessment.git
npm install
npx playwright install
4. Run the complete set of tests (note : workers have been set to 4 currently - you can change this in package.json under the 'test' script command)
npm run test
If you have used the 'npm run test' command in the previous instruction, then the cucumber report will open automatically once the test has finished.
Otherwise you can enter the following command from the cli (post test run) :
npx http-server ./cucumber-report -c-1 -a localhost -o index.html
-
Will be using Imperative style BDD
-
Will use localling running browsers - chromium, firefox and webkit
-
Config will be required for both desktop
and mobile simulated devices (time permitting)(only desktop achieved within time frame) -
Will use page objects as part of fixtures
-
Test steps will be as generic as possible if appropiate to aid maintainaility and reuse
-
It would be possible to use 'decorators' for the 'Given, When, Then' steps in the page object but to simplify and aid readability will use separates steps file instead
-
Will try to leave more of the assertions within the 'Then' steps but some basic checks may be done in 'Given' setup state steps
-
Will screen shot on failure and retain video
-
Will strive for no flakey tests. Will use the -x and --repeat-each options when running and testing the pack
-
Will follow best practices such as
- testing user visible behaviour (using playwrights getBy locators where possible)
- isolated tests
- Using web first assertions which will autowait
- Follow DRY principles
-
There will be cases where I will have two simlar steps - such as the search box in the header or main page but will try and refine this down to options in one step (time permitting)
-
An assumtion has been made, for the naviation check success assertion that most of the pages will have a H1 heading for the partiular topic (except for Home page)
-
Assuming tools like Prettier and linting are out of scope
-
The steps are currently contains in one file (Given, When, Then) - would consider splitting these into separate files for clarity but will leave for now
-
Page Object Methods are part of Class but not instance of the class via constructor (may change this)
- Focused on the search box in the header, but a reusable search function could be implemented. An option to specify either a 'header' or 'main' page search could be included, allowing both search boxes to be checked with minimal code effort.
- Mocking of results using playwright api mocking feature would be potentially useful as relying on data which may potentially change??
- I added an extra test here to check the error message when no text is entered to search for but the apply search button is pressed
As the site can use both keyboard or mouse I want to include that as an option for navigating using a single function but passing in an argument of inputDevice in a step. The aim is to use the "Tab" and "Enter" keys to navigate down to the menu item (evaluating when each item is in focus) and the selecting the correct option Of course a simpler method would have been to go directly to the Timeline content block URL but that would not test the UI
Note
Tabs not working correctly in webkit for the menu items - need to investigate (bypassed the tabbing for webkit for now)
Reused the site navigation pageobject functions for using keyboard etc. Added some new ones in the exploreTheCollections page object. The selectLetterIfEnabled function will fail if the test specifies to browse by a letter which has no associated collection, otherwise it will tab to (or click on) a letter and select it.
I really enjoyed creating these tests using Playwright-BDD. Given more time, I would have refined the test steps further to make them even more reusable and generic.
For execution, I used the three basic local browser configurations with video and snapshot enabled.
I had hoped to include mobile tests, as they would have influenced the structure of certain methods and steps. The goal was for the test run to automatically detect the project or platform and adapt selectors accordingly. Additionally, it would have been possible to tag specific tests as @mobile_only or @desktop_only, but unfortunately, I ran out of time.
