Playwright Beginner Tutorial 6 | How to use Trace Viewer

▬ ASK RAGHAV ► bit.ly/2CoJGWf
▬ QUIZ ► forms.gle/8vbYLzrneJXjukjVA
00:00 Intro
01:05 What is Trace Viewer
Trace Viewer is a GUI tool that helps viewing the executed test along with snapshots, timeline and other details (traces)
03:14 How to use Trace Viewer
Step 1 - Open config file and set trace: 'on-first-retry'
It means - Collect trace when retrying the failed test for the 1st time only
Step 2 - Save and Run a test to fail
Step 3 - Check trace.zip file created under test-results folder
Step 4 - View trace - npx playwright show-trace trace.zip
14:28 Screenshot moment
14:34 Trace Viewer Options
'on-first-retry' - Record a trace only when retrying a test for the first time.
'off' - Do not record a trace.
'on' - Record a trace for each test. (not recommended as it's performance heavy)
'retain-on-failure' - Record a trace for each test, but remove it from successful test runs
To set trace on from command npx playwright test --trace on
15:32 Screenshot moment
15:56 Different ways to view trace
Using command - npx playwright show-trace trace.zip
Using HTML Report
Using utility - trace.playwright.dev/
17:12 How to set Tracing programmatically
test.only('test demo', async ({ page, context }) =＞ {
await context.tracing.start({snapshots: true, screenshots: true})
// test code
await context.tracing.stop({path: 'test-trace.zip'});
});
let context
let page
test.beforeAll(async ({ browser }) =＞ {
context = await browser.newContext()
await context.tracing.start({ screenshots: true, snapshots: true })
page = await context.newPage()
})
test.afterAll(async () =＞ {
await context.tracing.stop({ path: 'test-trace.zip' });
})
38:24 Outro
#playwright #automation #testing
▬ ALL FREE COURSES ► automationstepbystep.com/
▬▬ CI CD DEVOPS ▬▬
JENKINS BEGINNER ► bit.ly/2MIn8EC
JENKINS TIPS & TRICKS ►bit.ly/2LRt6xC
JENKINSFILE ► bit.ly/3JSMSZ7
DOCKER ► bit.ly/2MInnzx
KUBERNETES ► bit.ly/2MJIlMK
▬▬ UI TESTING ▬▬
SELENIUM BEGINNERS ► bit.ly/2MGRS8K
SELENIUM JAVA FRAMEWORK ► bit.ly/2N9xvR6
SELENIUM PYTHON ► bit.ly/2oyMp5x
SELENIUM TIPS ► bit.ly/2owxc50
SELENIUM BUILDER ► bit.ly/2MKNtlq
SELENIUM 4 ► bit.ly/3AiJOlP
KATALON STUDIO ► bit.ly/2wARFdi
ROBOT FRAMEWORK with RIDE ► bit.ly/2Px6Ue9
ROBOT FRAMEWORK with Eclipse► bit.ly/2N8DZxb
PROTRACTOR ► bit.ly/2KtqVkU
ACCELQ ► bit.ly/3PlsAsh
TEST PROJECT ► bit.ly/2DRNJYE
CUCUMBER BDD ► bit.ly/3Cnno4z
CYPRESS ► bit.ly/3PpEukM
XPATH & WEB LOCATORS ► bit.ly/3PpEvoQ
▬▬ API TESTING ▬▬
WEB SERVICES (API) ► bit.ly/2MGafL7
SOAPUI ► bit.ly/2MGahmd
POSTMAN ► bit.ly/2wz8LrW
POSTMAN 2022 ► bit.ly/3JWm4qX
JMETER API TESTING ► bit.ly/3AgVPar
GENERAL ► bit.ly/2PYdwmV
KATALON STUDIO API ► bit.ly/2BwuCTN
REST ASSURED ► bit.ly/3zUdhRD
KARATE API ► bit.ly/3w3H5Ku
API MOCKING ► bit.ly/3bYPsjS
JMETER BEGINNER ► bit.ly/2oBbtIU
Visual Studio Code ► bit.ly/2V15yvt
JAVA BEGINNERS ► bit.ly/2PVUcXs
GROOVY ► bit.ly/2FvWV5C
JAVASCRIPT ► bit.ly/2KJDZ8o
TYPESCRIPT ► bit.ly/3dvJBmz
PYTHON ► bit.ly/2Z4iRye
MAVEN ► bit.ly/2NJdDRS
GRADLE ► bit.ly/30l3h1B
GIT & GITHUB ►bit.ly/2Q1pagY
GITLAB ► bit.ly/2kQPGyQ
BROWSERSTACK ► bit.ly/3w7kxZn
SAUCELABS ► bit.ly/3w7kAo1
LAMBDATEST ► bit.ly/3C6TBwM
JSON ► bit.ly/3w450tq
XML ► bit.ly/3PqRneH
VIRTUALIZATION ON WINDOWS ► bit.ly/2SItIL9
MOCK INTERVIEWS ► bit.ly/3QGwwVJ
QnA FRIDAY ► bit.ly/2NgwGpw
SUNDAY SPECIAL ► bit.ly/2wB23BO
STORIES BY RAGHAV ► automationstepbystep.com/stor...
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Every LIKE & SUBSCRIPTION gives me great motivation to keep working for you
You can support my mission for education by sharing this knowledge and helping as many people as you can
If my work has helped you, consider helping any animal near you, in any way you can
NEVER STOP LEARNING
Raghav Pal

[@ruixue6955]

1:40 screen shot of *trace viewer* 3:15 how to use *Trace Viewer*

[@RaghavPal]

Thanks for adding timestamps

[@technical.writer]

I am an absolut beginner, very proud to have followed until here and very curious for the upcoming sessions. Thank you for these great instructions!

[@RaghavPal]

You're very welcome Ralf

[@mukmusicdiary]

Another wonderful video! Appreciate your wonderful work :)

[@RaghavPal]

Most welcome

[@arrrysarkisyan9953]

u re incredible teacher :)

[@RaghavPal]

Thanks a lot

[@raghusp5719]

Thank you so much for your teaching.

[@RaghavPal]

You are very welcome

[@swathis3992]

Thank you for the sessions, Happy Teachers Day sir

[@RaghavPal]

You are welcome and same to you Swathi

[@TheMMakif]

Amazing. Thank you 👍

[@RaghavPal]

Most welcome Akif

[@faisaljayadi1173]

Amazing pak u a great teacher

[@RaghavPal]

Thanks and welcome Faisal

[@Anto-fz2kw]

my score 10/10. thank

[@RaghavPal]

Great.. you are doing very well since the beginning

[@sivaiahb]

Hi sir, your videos are so good to learn. these videos are so helping to me. pls help me by doing video on Data parameterization through CSV, Xlsx files

[@RaghavPal]

Thanks for watching. I will plan

[@ArunYadav23]

Hi Raghav, I am also a beginner - Playwright with javascript, your tutorial is helping me a lot to understand the plyawright. Qus : if i am not adding '.spec' in my .js file name the command to run the test ie 'npx playwright test' is not picking the .js file, can you plz tell why this keyword is require in .js file naming convension?

[@RaghavPal]

Hi Arun In Playwright, test files are usually written with a .spec.js extension. The .spec part of the extension signifies that it is a test file. When you run the command npx playwright test, it looks for files with a .spec.js extension and executes them. If you do not include the .spec part in the file name, the test runner may not recognize it as a test file and skip it. However, it is possible to run a test file with a different extension using the --test-match option when running the test command. For example, if your test files have a .test.js extension, you can run the tests using the following command: npx playwright test --test-match="**/*.test.js"

[@alpozturk6051]

Hi @RahgavPal. Can we get a detailed report (OS, Browser, Time etc.) when we run one or more tests successfully in Playwright? Thanks in advanced.

[@RaghavPal]

Alp Yes, you can get a detailed report (OS, browser, time, etc.) when you run one or more tests successfully in Playwright. To do this, you can use the `--reporter` option. The `--reporter` option allows you to specify a reporter to generate a report of the test results. Playwright provides a number of built-in reporters, including: * **html:** Generates a self-contained HTML report that can be served as a web page. * **json:** Generates a JSON report that can be used by other tools. * **list:** Generates a simple list of the test results. To generate a detailed report, you can use the `html` reporter. To do this, specify the `html` reporter in the `--reporter` option. For example, the following command will run all of the tests in the `my-tests.js` file and generate an HTML report: ``` npx playwright test my-tests.js --reporter=html ``` The HTML report will contain a detailed report of the test results, including the OS, browser, time, and other information. You can open the HTML report in a web browser to view it. In addition to the built-in reporters, there are also a number of third-party reporters available for Playwright. These third-party reporters can provide even more detailed reports, such as reports that include screenshots and videos. I hope this helps

[@christophermoffit5821]

thanks for all your help from your videos. I was able to automate multiple websites from your tutorials. I am kind of stuck though on a few websites. I see the Traceveiwer allows us to get more in depth on what error is occuring but what do I do if the code i am using i got from the playwright codegen? Now the file runs brings up the browser and enter a few text boxes but stops before completing page. Terminal is reading it came as a error for lets say the password text box. How do i go about fixing this if the code came directly from the codegen

[@RaghavPal]

Christopher Here's how to troubleshoot the error you're encountering with Playwright code generated by codegen: 1. Inspect Trace Viewer Output: Open the Trace Viewer (usually by pressing F12 in the browser). Examine the timeline for the failed action (e.g., interacting with the password text box). Identify specific error messages or clues about the issue. 2. Manually Reproduce the Error: Try interacting with the password text box manually in the browser. Observe any unexpected behavior or error messages. 3. Adjust Code Generation Strategy: Experiment with different codegen strategies (e.g., page.fill(), page.locator(), page.click()) to find the most reliable approach for the problematic element. Use manual selectors for complex elements if codegen selectors are unstable. 4. Address Dynamic Content and Timing Issues: If the element is dynamically loaded or hidden, use page.waitForSelector() or similar methods to ensure its presence before interacting with it. Use page.waitForFunction() to wait for specific JavaScript events or conditions. 5. Check for Element State Changes: Verify that the element is visible, enabled, and interactive before attempting actions on it. Use page.evaluate() to inspect element properties and states. 6. Debugging Tips: Use await page.pause() to pause script execution and inspect the page manually. Add console.log statements to track execution flow and variable values. Break down actions into smaller steps for easier debugging. Consult Playwright documentation and community resources for specific error messages or troubleshooting guidance. Specific to Password Error: Double-check the selector for the password text box. Ensure the password value is being entered correctly. Handle any autocomplete features or password managers that might interfere. Verify if any validation errors or restrictions are preventing submission. Remember: Codegen is a powerful tool, but it may not always produce perfect code Be prepared to make manual adjustments and use debugging techniques to resolve issues

[@user-bg5dk1xo9w]

Hi Raghav, I want to know if its possible to run a test from the middle ? For example, I make some changes in the code where the test fails, and I keep the corresponding webpage open, where I need to check whether the modified code is working.So is it possible to run and verify just that line of code?

[@RaghavPal]

Anushka While Playwright doesn't provide a direct mechanism to run a specific line of code from the middle of a test, you can achieve a similar effect by strategically utilizing breakpoints and conditional execution. 1. **Use Breakpoints:** Place a breakpoint at the line of code where you want to start executing the test. When you run the test, Playwright will pause at the breakpoint, allowing you to inspect the current state of the webpage and verify the modified code. 2. **Conditional Execution:** Enclose the remaining portion of the test code within a conditional block that checks a specific condition related to the modified code. This ensures that only the relevant portion of the test is executed when you resume from the breakpoint. For example, if the modified code is responsible for updating a specific element's content, you could check if the updated content is present before proceeding with the rest of the test. Here's an example of how to use breakpoints and conditional execution: ```javascript // Set breakpoint at the desired line debugger; // Conditional execution based on modified code if (isElementUpdated()) { // Continue executing test steps // ... } else { // Test case failed, handle accordingly // ... } ``` By combining breakpoints and conditional execution, you can effectively run and verify just the portion of the test that is relevant to your code changes. This approach provides a more focused and efficient way to test specific code modifications without having to run the entire test suite from the beginning.

[@user-bg5dk1xo9w]

thank you so much@@RaghavPal

[@letramytran7524]

Hi Raghav, how can we generate a unique report folder each time we run the test by using the playwright.config.ts file? Example: I put this line to the config file reporter: [['html', { outputFolder: 'my-report'}]], I don't know how to add the timestamp to the folder name to be my-report-12345645 for example, can you help me?

[@RaghavPal]

Lê To generate a unique report folder each time you run the test, you can use the `outputFolder` option in the `reporter` configuration. The `outputFolder` option takes a string as its value, which is the path to the folder where the report should be generated. You can use the `${timestamp}` placeholder in the string to include the current timestamp in the folder name. For example, the following configuration will generate a report folder with the name `my-report-12345645`: ``` reporter: [['html', { outputFolder: 'my-report-${timestamp}' }]], ``` The `timestamp` placeholder is replaced with the current Unix timestamp in milliseconds. This will ensure that each report folder is unique. Here is an example of how to use the `outputFolder` option in the `playwright.config.ts` file: ``` import { defineConfig } from '@playwright/test'; export default defineConfig({ reporter: [['html', { outputFolder: 'my-report-${timestamp}' }]], }); ``` I hope this helps!

[@cosminmatic5987]

@@RaghavPalHi Raghav! Where "reporter" configuration can be found? There is no such point in the config file

[@cosminmatic5987]

Hi Raghav! I have a record created with default settings. When running it, it passes when using project chromium and webkit but it failes with firefox. In order to avoid this should i make separately a record with firefox ?

[@RaghavPal]

When using Playwright to record tests, it's essential to consider browser compatibility. Let's address your situation: 1. Test Generation with Playwright: - Playwright provides a test generator that allows you to record your actions in the browser and automatically generate test code. This is a great way to quickly create tests. - You can use the VS Code extension to generate tests directly from VS Code. The extension prioritizes locators (such as role, text, and test ID) to identify target elements. - Assertions (like visibility, text content, or element value) can also be generated based on your interactions with the page 2. Recording Tests with Playwright: - To record a new test, click the "Record new" button from the Testing sidebar. This will create a test file (e.g., `test-1.spec.ts`) and open a browser window. - Navigate to the URL you want to test and perform your user actions. Playwright will record these actions and generate the corresponding test code directly in VS Code. - You can also generate assertions by choosing icons in the toolbar and clicking on elements to assert against 3. Separate Recordings for Different Browsers: - If you encounter issues with a specific browser (such as Firefox), consider recording separate tests for each browser. - While Playwright aims for cross-browser compatibility, some features may behave differently or have limitations in certain browsers. - By recording separate tests for each browser (e.g., one for Chromium, one for WebKit, and another for Firefox), you can tailor your test scenarios to each browser's behavior. 4. Firefox Compatibility: - Playwright doesn't work with the branded version of Firefox due to reliance on specific patches - However, you can still use Playwright with the local Firefox installation by launching it explicitly In summary, if you want to ensure compatibility across different browsers, consider creating separate recordings for each browser. This approach allows you to fine-tune your tests and handle any browser-specific quirks.

[@singh07neeraj]

Hi Raghav , what is the meaning of trace: 'retry-with-trace', 'retry-with-trace here , I tired to find answer in google but not able to understand

[@RaghavPal]

Hi Neeraj In Playwright, the trace option allows you to capture a trace file during the test execution, which contains detailed information about the browser activity, network requests, and other events that occur during the test. The retry-with-trace option is used when a test fails due to a Playwright issue. When this option is enabled, Playwright will automatically retry the failed test with tracing enabled to capture more information about the issue. The retry-with-trace option will retry the test up to three times by default, with each retry generating a new trace file. The retry-with-trace option is useful for debugging and troubleshooting issues with your test scripts. When you enable this option, you can get more detailed information about the error, which can help you to identify and fix the underlying issue. The retry-with-trace option can be set at different levels in Playwright, such as the test, describe, or suite levels. When set at a higher level, such as the describe or suite levels, the option will apply to all tests within that group

[@svksuman]

Hello sir, please explain us trace viewer ..in eclipse pom model.. And can we capture both video and snapshots in eclipse pom model...pls share ...

[@RaghavPal]

Hi Suman Playwright's Trace Viewer is a powerful tool that allows you to analyze the performance and behavior of your Playwright tests. It provides a detailed timeline of events that occur during your test, such as page loads, network requests, and user interactions. To use the Trace Viewer in Eclipse with Maven, you can add the Playwright Trace Viewer plugin to your project's pom.xml file. Here's an example configuration: com.microsoft.playwright playwright-maven-plugin 1.15.0 run-tests integration-test test com.microsoft.playwright playwright-trace-viewer-maven-plugin 1.15.0 generate-trace-report post-integration-test generate This configuration sets up the playwright-maven-plugin to run your Playwright tests during the integration-test phase and the playwright-trace-viewer-maven-plugin to generate a trace report after the tests have completed during the post-integration-test phase. To capture both videos and screenshots during your Playwright tests, you can use the contextOptions and browserOptions configuration options in your test code. Here's an example: const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch({ headless: false }); const context = await browser.newContext({ recordVideo: { dir: './videos/', }, screenshot: { dir: './screenshots/', }, }); const page = await context.newPage(); await page.goto('example.com'); await page.screenshot({ path: './screenshots/example.png' }); await browser.close(); })(); This code sets up a Chromium browser instance with the headless option set to false to enable video recording, and configures the recordVideo and screenshot options in the newContext method to specify the directories where videos and screenshots should be saved. You can also use the recordVideo.size option to specify the dimensions of the video recording. With these configurations in place, you should be able to use Playwright's Trace Viewer to analyze the performance of your tests and review the videos and screenshots captured during the test run.

[@jatn-xe7mh]

Thanks for the valuable session , but i am not getting screenshots when we code in beforeAll function in example.spec.Could you please help with some suggestion

[@RaghavPal]

Hi Jatn, If you are not getting screenshots when you are running your test code inside the beforeAll function in your example.spec file using Playwright, there are a few things you can try to debug the issue: Ensure that the beforeAll function is being executed: You can add a console.log statement inside the beforeAll function to check if it is being executed or not. If it is not being executed, you may need to check if there are any errors or issues with the test setup. Check if the page is being loaded properly: Playwright takes screenshots of the page, so if the page is not being loaded properly, you may not get any screenshots. You can try adding a console.log statement to check if the page is being loaded successfully or not. If it is not being loaded, you may need to investigate why. Verify the path where the screenshots are being saved: Playwright saves the screenshots in the directory specified in the context.screenshotter.options.path option. You can check if the screenshots are being saved in the correct directory by verifying the path specified in the context.screenshotter.options.path option. Add a delay before taking the screenshot: If the screenshot is being taken before the page has fully loaded, you may not get the expected results. You can try adding a delay before taking the screenshot using the setTimeout function. Here's an example of how you can add a delay before taking a screenshot in the beforeAll function: describe('Example', () => { beforeAll(async () => { await page.goto('www.example.com'); await page.waitForLoadState('networkidle'); await setTimeout(async () => { await page.screenshot({ path: 'screenshot.png' }); }, 3000); }); it('should pass', async () => { // your test code here }); }); In this example, we are adding a delay of 3 seconds before taking the screenshot to ensure that the page has fully loaded before taking the screenshot. You can adjust the delay time as per your needs.

[@cnjbravo]

Hi Raghav, good day. I'm trying to create the trace file using context.tracing in my test file but never is created. I have the same values in the playwright.config.ts with "retries: 1,". Do you know what can be happening?

[@cnjbravo]

It works only when I add test.beforeAll and test.afterAll. I think it should work on both scenarios, right?

[@RaghavPal]

Jorge For the issue with creating trace files using Playwright and understand why it works only when you add `test.beforeAll` and `test.afterAll`. Here are some insights and steps to help you: 1. Understanding Test Retries and Tracing: - When you enable test retries in Playwright, failing tests are retried multiple times until they pass or reach the maximum number of retries. - By default, failing tests are not retried. You can configure retries in the `playwright.config.ts` file. 2. Tracing Options: - To create trace files, you have a couple of options: - Use `context.tracing` within individual tests. - Set `trace: 'retain-on-failure'` in your configuration to retain traces for failed tests even without retries. 3. Why It Works with `test.beforeAll` and `test.afterAll`: - When you add `test.beforeAll` and `test.afterAll`, they run once per worker process (before and after all tests). - If a test fails and retries are enabled, the entire worker process (including the browser context) is discarded and a new one is created. - When you use `test.beforeAll` and `test.afterAll`, the browser context is created only once, and subsequent retries reuse the same context. - This behavior ensures that traces are retained for failed tests across retries. 4. Without `test.beforeAll` and `test.afterAll`: - If you don't use `test.beforeAll` and `test.afterAll`, each test runs in its own isolated context. - When a test fails, the entire context (including traces) is discarded, and a new context is created for the next test. - This behavior prevents traces from being retained across retries. 5. Solution: - If you want to retain traces for failed tests without using `test.beforeAll` and `test.afterAll`, consider setting `trace: 'retain-on-failure'` in your configuration. - Adjust your configuration in `playwright.config.ts`: ```typescript export default { // Other configuration options... trace: 'retain-on-failure', // ... }; ``` 6. Verify Your Configuration: - Double-check your `playwright.config.ts` to ensure that the `trace` option is set correctly. - Make sure you're using the correct configuration file (sometimes there might be multiple config files). Remember that the behavior of traces and retries depends on your test setup and configuration. Adjust your configuration based on your requirements. all the best..

[@Mr47CRO]

My trace report that I put for a specific test by adding at the beginning: await page.context().tracing.start({ screenshots: true, snapshots: true }); and at the end of my test: const tracePath = await page.context().tracing.stop(); is giving me a strange file that is not a zip file and cannot be opened by trace viewer. Do you know how can I fix that?

[@RaghavPal]

James It seems like you're encountering an issue with your Playwright trace report. Let's troubleshoot this: 1. Trace Format: - Playwright generates trace files in a ZIP format by default. If you're getting a strange file that isn't a ZIP, it might be due to an issue during the trace recording process. - Ensure that you're using the correct method to start and stop tracing. You mentioned using `await page.context().tracing.start({ screenshots: true, snapshots: true })` and `await page.context().tracing.stop()`, which is correct. 2. Possible Solutions: - Let's try a few steps to resolve this: - Check Permissions: Ensure that the directory where you're saving the trace file has proper write permissions. - File Extension: Double-check that the file extension is indeed `.zip`. Sometimes file extensions can get changed inadvertently. - Corrupted File: If the file is still not opening as a ZIP, it might be corrupted. Try recording the trace again and see if the issue persists. - Browser Context: Make sure you're stopping tracing on the correct browser context. If you're using multiple contexts, ensure you're stopping tracing on the one you started. 3. Opening the Trace: - To open the saved trace, you have a couple of options: - Using Playwright CLI: - Use the following command to open the trace locally: ``` npx playwright show-trace path/to/trace.zip ``` - Replace `path/to/trace.zip` with the actual path to your trace file. - Online Trace Viewer: - You can also upload your trace to [trace.playwright.dev](trace.playwright.dev/) directly in your browser. - Make sure to provide the full path to your trace ZIP file when opening it online. 4. CI Integration: - If you're running traces on continuous integration (CI), consider using the `trace: 'on-first-retry'` option in your test configuration file. This will produce a separate `trace.zip` file for each retried test Remember to verify the permissions, file extension, and context when recording and opening traces

[@DK-ik3bf]

Hi Raghav, I'm struggling to use the trace viewer. I already changed the retries in the config file to trace: 'on-first-retry', and retries: 1,. I have the same folder structure as yours but when I added the command: "npx playwright show-trace rec1_demo.spec.js" it would open the trace viewer but there's an error says"Could not load trace from rec1_demo.spec.js. Make sure a valid Playwright Trace is accessible over this url." and when I selected the file from the folder it also still could not load it. What did I miss? Thank you

[@RaghavPal]

D K I understand that using the Playwright Trace Viewer can be a bit tricky, but let's troubleshoot this 1. Trace Generation: - First, ensure that you've generated a trace file during your test execution. You mentioned setting `trace: 'on-first-retry'` in your configuration file, which is great! This should produce a `trace.zip` file for each retried test. - Make sure you're running your tests with the trace option enabled: ```bash npx playwright test --trace on ``` - After running your tests, check if the `trace.zip` file exists in your project directory. 2. Opening the Trace Viewer: - To open the trace viewer, use the following command: ```bash npx playwright show-trace trace.zip ``` - If you encounter the error "Could not load trace from rec1_demo.spec.js," it means the viewer is trying to load the trace from a URL (which doesn't exist in this case). - Instead, you should provide the path to the `trace.zip` file directly. Make sure you're executing this command in the same directory where the `trace.zip` file is located. 3. Local vs. Browser Mode: - The trace viewer can be opened locally or in your browser. - To open it locally, use the command above. It will launch a local web server and display the trace viewer in your default browser. - To open it in your browser, visit [trace.playwright.dev](trace.playwright.dev/) and upload the `trace.zip` file there. 4. Troubleshooting: - If you're still facing issues, consider the following: - Check if your browser is up-to-date. - Clear your browser cache and try again. - Ensure that the `trace.zip` file is not corrupted. - If you're using a custom server, make sure it's serving the trace files correctly.

[@DK-ik3bf]

@@RaghavPal Ah great! Thank you for the help! I think I missed this step: npx playwright test --trace on. Now I can have my trace.zip file :)

[@DK-ik3bf]

Hi @RaghavPal, another question, I have the code same as yours: let context; let page; test.beforeAll(async ({browser}) => { context = await browser.newContext(); await context.tracing.start({ snapshots: true, screenshots: true }); page = await context.newPage(); }) test.afterAll(async () => { await context.tracing.stop({ path: 'test2_trace.zip'}) }) and when I run this I got: "Error: Must start tracing before stopping" What did I miss? Should I put the after hook after the test I want to run? Or can I put it right after the before hook? Thank you

[@RaghavPal]

The error message you're encountering, "Error: Must start tracing before stopping," indicates that you're trying to stop tracing without having started it first. Let's address this issue: 1. Order of Execution: - In your current code, the `test.beforeAll` hook starts tracing, and the `test.afterAll` hook stops it. - The error suggests that you're trying to stop tracing before it has been started. 2. Correct Order: - To resolve this, ensure that you start tracing before stopping it. - You can move the `test.afterAll` hook after the actual test execution (e.g., after your test case). 3. Updated Code: - Here's an example of how you can adjust your code: ```javascript let context; let page; test.beforeAll(async ({ browser }) => { context = await browser.newContext(); await context.tracing.start({ snapshots: true, screenshots: true, }); page = await context.newPage(); }); test('Your Test Case', async () => { // Your test logic here }); test.afterAll(async () => { await context.tracing.stop({ path: 'test2_trace.zip' }); }); ``` 4. Test Execution Order: - Keep in mind that `test.beforeAll` runs before any test cases, and `test.afterAll` runs after all test cases. - If you have multiple test cases, the tracing will be started before any test runs and stopped after all tests have completed. Remember to adjust the code according to your specific test cases and requirements. ..

[@exploreNepalBeauty]

"ReferenceError: context is not defined" error is thrown from [await context.tracing.stop({path: 'test1_trace.zip'})]. await context.tracing.start is working fine . Help me When I delcare as let context; Error "TypeError: Cannot read properties of undefined (reading 'tracing')" is shown. Stuck at 22:22 and not being able to get output as shown in your screen.

[@RaghavPal]

The "ReferenceError: context is not defined" error typically occurs when the context variable has not been defined or has been defined outside of the scope where it is being used. To fix this issue, you should ensure that the context variable is defined before it is used in the code. Here is an example of how to define context before using it for tracing: const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch(); const context = await browser.newContext(); // Enable tracing await context.tracing.start({path: 'test1_trace'}); // Perform actions on the page // Stop tracing await context.tracing.stop(); await browser.close(); })(); Make sure to define the context variable within the scope where it is being used, and ensure that it is not being redefined or undefined within the same scope.

[@exploreNepalBeauty]

@@RaghavPal Thank you so much for this explanation. Actually, my mistake was I started tracing in one test and stopped tracing in another class. Thank you for your efforts, Sir

[@sreelajanair3730]

Hi.. For me the trace zip files are getting replaced with the latest file. The previous file getting removed. Could you help me fix the issue?

[@RaghavPal]

Hi Sreelaja Here are the steps on how to prevent the trace zip files from getting replaced with the latest file in Playwright: 1. In your `wdio.conf.js` file, add the following code: ``` trace: { path: './traces', maxSize: 10000000, replace: false }, ``` This will tell Playwright to not replace the trace zip files. Instead, it will create a new trace zip file for each test run. 2. The `path` property specifies the directory where the trace zip files will be saved. 3. The `maxSize` property specifies the maximum size of a trace zip file. If a trace zip file exceeds this size, it will be deleted. 4. The `replace` property specifies whether or not Playwright should replace the existing trace zip files. If this property is set to `false`, Playwright will create a new trace zip file for each test run. Here are some additional things to keep in mind: * The `trace` property is optional. If you do not specify this property, Playwright will not create any trace zip files. * The `path` property must be an absolute path. * The `maxSize` property is in bytes. * The `replace` property can only be set to `true` or `false`. I hope this helps

[@NikitaFondekar-rz3mb]

Hi @Raghav Sir not able to trace website like amazon for testing purpose can u tell me why is it so

[@RaghavPal]

Nikita When using Playwright for testing websites like Amazon, you might encounter difficulties with tracing due to several reasons: 1. Complex Page Structure: Websites like Amazon have complex structures with dynamic content that can make tracing challenging. Playwright's tracing feature captures the actions, network requests, and console logs, but if the page has many asynchronous operations, it might be hard to follow. 2. Anti-Bot Mechanisms: Some websites have mechanisms to detect and block automated testing tools like Playwright. This could prevent Playwright from performing actions on the site as it would normally do in a browser controlled by a human. 3. Browser Compatibility: Ensure that you're using a compatible browser with Playwright. While Playwright supports multiple browsers, there might be specific features or behaviors in Amazon's website that are optimized for certain browsers. 4. Network Issues: Network configurations or restrictions could interfere with Playwright's ability to trace actions on a website. Check your network settings and permissions. 5. Playwright Configuration: Your Playwright configuration might need adjustments. For example, ensuring that the `tracing.start()` method is called before any actions are performed and `tracing.stop()` is called at the end of the session. 6. Version Compatibility: Make sure you're using the latest version of Playwright, as older versions might not fully support all features required for tracing complex websites. Remember, when testing on live websites, always comply with the site's terms of service and use testing accounts or environments provided by the website if available.

[@uvplays4349]

Hi Raghav, thank you for the video, I'm getting this error: "SyntaxError: await is only valid in async functions and the top level bodies of modules Error: No tests found. Make sure that arguments are regular expressions matching test files. You may need to escape symbols like "$" or "*" and quote the arguments." I'm new to Type script, could you please help with this, thank you.

[@RaghavPal]

Here's a breakdown of the error and how to resolve it: Error Breakdown: 1. "SyntaxError: await is only valid in async functions and the top level bodies of modules": This error indicates you're using the `await` keyword outside of an `async` function or the top-level of a module in TypeScript. In Playwright, most test-related operations involve asynchronous interactions, so using `async` functions is essential. 2. "Error: No tests found. Make sure that arguments are regular expressions matching test files. You may need to escape symbols like "$" or "*" and quote the arguments.": This error suggests that Playwright couldn't find any test files based on the arguments you provided in your command. It also reminds you to handle special characters in filenames correctly. Solutions: 1. Wrap your test code in `async` functions: Ensure all code blocks where you use `await` are encapsulated within `async` functions. For example: ```typescript test('Test case name', async ({ page }) => { // Your test logic using await keyword here }); ``` 2. Verify and adjust test file arguments: Double-check the arguments you're using in your Playwright command to specify test files. If you're using regular expressions, make sure they are correct and properly escaped: ```bash npx playwright test src//*.test.ts # Find all test files in "src" directory npx playwright test "src/features/login.test.ts" # Specific test file npx playwright test ".*feature.*.test.ts" # Wildcard for files ending with "feature" and starting with .test.ts ``` 3. Ensure correct TypeScript configuration: TypeScript has strict syntax rules. Make sure your project is configured correctly and there are no errors preventing compilation. Check for compilation errors or missing dependencies, especially related to Playwright and TypeScript. Additional Tips: Start with a simple test: Write a basic test first, like navigating to a webpage, to verify your setup and syntax are correct. Consult Playwright documentation and examples: The Playwright documentation provides numerous examples and guides to help you learn the testing framework and common practices. Consider using a code editor with TypeScript support: Many code editors offer syntax highlighting and error checking to assist with TypeScript development. ..

[@uvplays4349]

thanks a lot @@RaghavPal very clear explanation, will follow the instructions.

[@mihaelacostea5783]

how come it opens up a report after execution, did you set it up like that? For me it doesnt open up any report....

[@mihaelacostea5783]

Alao nothing is saved in my test-results folder, it stays empty...

[@RaghavPal]

Hi Mihaela will need to check the details, may be due to version change

[@katdareshruti]

I had the same issue, but it fixed after adding the trace: 'on-first-retry' in config file and adding some error to the js test file. Once retry happens and test completes, the report automatically opens.

[@anuragupadhyay9438]

can we integerate trace in cucumber? Please suggest

[@RaghavPal]

Hi Anurag do you mean in a custom standalone cucumber bdd project? I am not sure on this

[@user-bu6xn5vb5g]

can i check trace file directly in jenkins?

[@RaghavPal]

Certainly! To view trace files directly in Jenkins, you can follow these steps: 1. Console Output: - When a Jenkins build runs, it captures the console output (logs) of the executed commands. - After a build completes, go to the build page (usually accessible via the build number or the "Build History" section). - Click on the build you're interested in, and then navigate to the "Console Output" link. - The console output will display the entire log, including any trace information from your executed commands. 2. Custom Log Files: - If your trace information is generated by a specific tool or script, you can create custom log files during your build process. - For example, if you're running a Maven build, you can configure Maven to generate a log file (`mvn clean install > mylog.txt`). - In your Jenkins job configuration, add a post-build step to archive or publish the log file. This way, you can access it directly from the Jenkins build page. 3. Plugins and Integrations: - Jenkins has various plugins that enhance its functionality. - Consider using plugins like the "Log Parser Plugin" or the "AnsiColor Plugin" to improve the readability of your console output. - Some plugins allow you to parse specific patterns (including trace information) and highlight them in the console log. 4. Artifact Archiving: - If your trace files are generated as artifacts (e.g., log files, reports), configure Jenkins to archive them. - In your Jenkins job configuration, add a post-build step to archive specific files or directories. - Archived artifacts can be accessed from the build page under the "Artifacts" section. Remember that Jenkins provides flexibility, and you can tailor your setup based on your specific needs.

[@sagarikamandal8977]

Score in quiz10. Curious about next video.

[@RaghavPal]

All the best Sagarika

[@ahmethalal6926]

Hi Raghav, Can you please give the complete code you used here?

[@RaghavPal]

Hi Ahmet, can check here - github.com/Raghav-Pal/Playwright_PageObjectModel

[@ahmethalal6926]

@@RaghavPal Hi Raghav, I was looking for the code you used for "How to use Trace Viewer". I'm getting errors if I follow your instructions.

[@RaghavPal]

ok, you can try some online examples for that

[@user-yc5wi6jt8l]

I am an beginner, in testing how i can fix this error PS D:\playwright_automaed_ extention_vs-code> npx playwright test .\test ecord1_demo.spec.js --headed --prError: No tests found To open last HTML report run: npx playwright show-report

[@RaghavPal]

Taher Try using forward slashes / in the path of the test file

[@Floweenka]

I am probably facing a bug with "Must start tracing before stopping" even tho I wrote the code correctly. Just to let another testers know they may not be alone :))

[@RaghavPal]

Hi, If you are encountering the "Must start tracing before stopping" error in Playwright even though you have correctly written the code, there may be a few possible causes. One possible cause is that you may be calling the stopTracing() method without calling the startTracing() method first. To fix this, make sure that you have called the startTracing() method before calling stopTracing(). Another possible cause is that the browser may have crashed or closed unexpectedly, which can lead to this error. To fix this, you can try relaunching the browser and running the script again. Finally, this error may be caused by a bug in Playwright itself. If you believe this is the case, you can try updating to the latest version of Playwright and see if the issue is resolved. You can also check the Playwright issue tracker on GitHub to see if this is a known issue, and if not, consider reporting the issue there. Overall, the "Must start tracing before stopping" error in Playwright can be caused by a variety of factors, and troubleshooting the issue may require a bit of experimentation and trial and error. By following the steps above, however, you should be able to resolve the issue and continue with your testing.

[@Floweenka]

@@RaghavPal I believe it's bug in Playwright because I had everything same as you, installed via VS Code extension - newest version. I have found that there was this bug before so maybe we have it again. Thanks a lot for your help

[@RaghavPal]

Most welcome, I will suggest to post this on Playwright support or community page

[@chijiokenjoku6265]

Hello @@Floweenka do you have any solution because currently I'm having same issue