Files to explore to understand how the functionality work:
- ./featureMap.yaml
- This is where you keep track of your features, user stories, test cases, or whatever you choose to track your coverage. I use the term "coverage" but the idea is that you can also use this logic for your documentation. It's a YAML file, which makes it very easy to organize features and test scenarios. If you're not familiar with YAML and want to learn more, please visit https://www.redhat.com/en/topics/automation/what-is-yaml.
- ./global-setup.ts
- If you want to calculate coverage and see the results in the terminal before running any tests, you need to pass
CALCULATE_COVERAGE=true
before thenpx playwright test
command. The ./featureMap.yaml file will be read, converted to JSON, and then passed to thecalculateUICoverage()
function.
- If you want to calculate coverage and see the results in the terminal before running any tests, you need to pass
- ./helpers/calculateUICoverage.ts
- The "magic" of actually calculating coverage happens in this file. The code could be improved, but I've left it this way to make it easier to read and understand the logic.
Files to explore to understand how the functionality works:
- ./helpers/createAssertions.ts
- You call the
createAssertions()
function and pass a response body. Assertions will be printed to the terminal, and all you'll have to do is copy and paste them into your test. The function can be modified to better fit your tests. For example, I have a custom expect: when a date is returned in the response body, the function generatesexpect(body.created_at).toBeValidDate()
. You can learn more about creating custom expects in Playwright here: https://playwrightsolutions.com/creating-custom-expects-in-playwright-how-to-write-your-own-assertions.
- You call the
Files to explore to understand how the functionality works:
- ./helpers/warnings.ts
- You call the
warnings()
function and pass a message you would like to be printed to the console after all tests are finished running.
- You call the
- ./warnings.log
- This file contains messages to be printed at the end of the run. There won't be a warnings file if no messages are added during test execution.
- ./global-setup.ts
- The warnings file is deleted before each run so that a new one can be created to append our messages.
- ./global-teardown.ts
- The warnings file is read, and all messages are printed to the console.
Mocking is awesome, but the way many people approach mocking API responses to test UI is not for me. I don't want to maintain hardcoded file(s). Playwright makes it super easy to mock API responses (see the official docs here: https://playwright.dev/docs/api/class-route#route-fulfill). My approach to mocking is as follows: I first make an actual API call to my servers to get the real-time structure of the object, then modify it as needed. By using Playwright's route.fulfill
, I pass the modified JSON. At this point, all I need to do is ensure that the UI displays what I expected.
Files to explore to understand how the functionality works:
- ./tests/uiTest.spec.ts
Playwright official docs: https://playwright.dev/docs/intro (they are amazing)
Another resource I highly recommend for those who work with or want to work with Playwright: https://playwrightsolutions.com
I would be happy to receive any feedback, so please feel free to connect or message me on LinkedIn: https://www.linkedin.com/in/sgapanovich/