Detailed Log Analysis | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: Test Management
Instructor: Artem Bondar
Lesson Summary
In this lesson, we explore how to obtain detailed information about test case execution for better debugging and analysis in Playwright. Understanding the Need for Detailed Logs While the framework can attach request and response details to reports, there are instances when this information is insufficient. For example, if a test fails or an API request does not go through, additional details may be necessary to identify issues such as: Missing headers Unexpected response data Using Playwright's Trace Feature Playwright offers a feature called Trace that collects comprehensive information about networking interactions. To enable Trace: Open playwright-config.ts . In the use block, add the Trace property. Set Trace to on or use the retain on failure option to save Trace only when tests fail. Analyzing Trace Data After running a test that fails, you can access the Trace data in the playwright-report folder. The Trace view includes: Network Tab: Displays all API requests made during the test. Request Details: Includes URL, method, status code, headers, and authorization tokens. Response Headers: Useful for understanding the context of subsequent API requests. Response Body: Provides the JSON body returned from the API. Reproducing Requests You can copy request details to reproduce the API call using options like copy as CURL or copy as Playwright . This feature allows you to generate the exact code executed during the test: const response = await page.request.get('URL', { headers: { ... } }); These tools enhance your ability to debug API tests effectively. For further assistance, refer to the next lesson.
Video Transcript
Hey guys, welcome back. In this lesson, I will show you how you can get more details about the test case execution in case you need more information for debugging and analysis. So currently, our framework configured to attach request details and response details directly into the report. But sometimes, it is not enough. Sometimes, still something just does not work as expected, your test failing, the API request does not go through, and you don't really understand why. In this case, you may need more details to analyze what's actually went wrong. Maybe some header is missing or something coming back in the response from the previous request, and you're missing that header and stuff like that. So Playwright has a feature called Trace, and Trace collect all the information about what happened during the networking interaction of the framework, and let me show you how to get this Trace. So going back to the framework, and first of all, we need to enable the Trace. Navigate to playwright-config.ts, and here in the use block, we need to add a property called Trace, this guy. This Trace has several configuration options. So by default, it's just off, it's not activated. You can set it as on. In this case, Trace will be attached to every report, but maybe it's a little bit too much. You don't need it because it will make your report, final report bigger and taking more size. One of the options that you can choose is retain on failure, this one. It will save the Trace only when the test fails. Otherwise, it will not save the Trace and will not attach to the reporter. So I set this value, and that's it. Going back to our test, and now let me fail the test. For example, I put some weird assertion that should fail, and let me run this test and see what's gonna happen. I run the test, and test expectedly fails. Now let's open the report, playwright-report. Look, we have a new folder over here with Trace. So this Trace will be attached to the reporter, and I open it in the default browser. Here's the Chrome browser opening the test. This is the normal details that are automatically attached about the request and response details. And if you scroll all the way down, here we go. You have a Trace over here. Click on the Trace, and now you have this little bit overloaded view. So first of all, this Trace primarily designed for UI automation. So that's why you see here is a blank page of the browser. We don't care about it. What we are looking for, we navigate over here to the Network tab, click right here, and the Network tab collects all the information, all the API requests that happened during the test. And these are two API requests that our test was actually performed. So first is login to get the access token, and the second is tags that were actually failing. And look, here you can have all the details. You have all the details about the request. Request details, URL, method, and status code. Request headers, and look, user agent. This is what actually playwright sent to the API under the hood. It said that, hey, the user agent is playwright 152. It's accept header like this. Encoding was used, this one. Sometimes your API may require some special encoding, and maybe the reason why your request didn't work because you didn't use the right encoding. This can be a clue. And authorization token and the duration. Also response headers, look at this. So these are response headers that came back after our request. Sometimes this information also can be useful for analysis to process the next API request, for example. Sometimes in the response headers can be some IDs or some other hidden information that might be important for the successful API request, and the actual body right here. So this is just a JSON body that is coming back that you can also take a look at. And one more thing, there is an option to copy the details about this request to reproduce this step one more time. And here is a dropdown copy as CURL, copy as fetch, or copy as a playwright. So if I, for example, copy as a playwright and go back to the code and paste it right here, look. So playwright automatically generated for us the exact code that was executed in kind of a playwright format. You see it using default page fixture, request, get, all headers that were used, and you can try to trigger this type of the request if something doesn't work. And the second option, the simpler one, is copy as CURL. So it will be copied just as a CURL, executable in any terminal. So I copy and paste it right here, all the details, and just hit Enter. Look, an API request was performed, and this is the list of the tags. So some of the useful tricks for the API test debugging in case you will need that. All right, I hope this was helpful. This is how you can get more information about API execution for the debugging purposes, and see you in the next lesson.