Playwright Configuration File | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: Building a Framework
Instructor: Artem Bondar
Lesson Summary
In this lesson, we focus on cleaning up the Playwright configuration file for API automation. Here are the key points covered: Removing Unnecessary Sections The section related to the web server is removed since it pertains to UI applications. Commented blocks for various browsers (e.g., Firefox , WebKit ) are not needed as they are unrelated to the project organization. Organizing Projects Create separate projects for different test types, such as smoke tests . Use testMatch to specify which tests to run based on naming conventions, e.g., using wildcards. Define project dependencies to ensure tests run in a specific order, e.g., running API tests only if smoke tests pass. Configuration Settings The use block is simplified; unnecessary settings like trace and base URL are removed. Important settings include extra HTTP headers and HTTP credentials for basic authorization. Reporters and Workers Use JUnit reporter for CI/CD integration, though HTML reporter is sufficient for most needs. Set the number of workers to one for API testing to maintain simplicity. Retries and Final Notes Configure retries for flaky tests; default is zero for local runs. Keep the configuration minimalistic, focusing on the essential elements for API testing. This streamlined approach enhances the efficiency of running API tests in Playwright.
Video Transcript
All right, guys, so in this lesson, we will clean up our Playwright configuration file a little bit, and I will show you some of the useful settings that you can use for API automation in the Playwright. Let's get into it. So this is the config file that we already touched before, and let's start with removing something that we don't need. Let's start from the bottom. So here is the section about the web server. That's related to UI applications. If you have a UI application that you want to run on a local host and then run your test against this application, this is when this section will be useful. We don't need it, we run API test, just remove it. Then the big section about the project. So here commented block like Firefox, WebKit, Microsoft Edge, Mobile Safari, and so on, and projects in Playwright are not related to the browser. So projects is the way how you can organize the test, group your test, and so on. Let me show you a few examples. So I remove some of the projects that are commented over here. So far, we have API testing general project that runs everything inside of our project. But we have smoke.spec.ts in example, spec.spec.ts. So let's separate them into a different projects. How you can do that? So you create a new project, provide the name, and for example, it will be a smoke tests, something like this. To specify that it will be a smoke test, you can define which tests it will run. So you have test directory and test match. So either the folder or particular test. So test match, and then you can create either the entire spec file or for example, the wildcard. For example, I type smoke and the asterisk. And all test files that have a smoke in their name will be executed if I trigger the execution of this project. So now I go back to the test explorer, and here in the bottom, I have a project. So I change the smoke test and remove API test, click refresh, reload, and look, only a single project is available for us. And then you can run the test using the terminal. So new terminal, NPX playwright test, dash dash project, and then smoke tests. I run the test and you see it's running only smoke test that spec.ts. All right, what else you can do with the projects? You can create a dependencies between the projects. For example, the API testing is the project that will run, for example, test match, run the rest of our test. The rest of the test is the example, example like this. And let's say that we want to run this project only if the smoke test will pass. So you can create a test dependency like this, dependencies, and define which projects have to be executed first before running this project. And we want to be dependent on the smoke test like this. And now when I run just a standard command, NPX playwright test, playwright would try to run all the projects inside of our framework, but we have only two projects. It will try to run both of them, but it will see that, hey, API testing project is dependent on the smoke test project. So first, this project will be executed and only then this one. So look at this, I'm running the test. First smoke tests are executed. When they passed, then the second project is triggered. But if I will fail any of the tests from the smoke test that spec.ts, for example, I fail this project and try to run it again, then you see first test from the smoke test failed and the second project was just skipped. It was not executed at all. So it can be also useful. Let's say you have a larger test suite that you have a smaller subset of the test with a smoke test and bigger subset of the test with other tests. And before running the entire test suite with the rest of the test, you want to make a smoke test first, and you can create this kind of a dependency. So if smoke test passed, then run the rest of the test. This is how it can be useful. All right, so what else? This is the projects, cleaning this up, moving on. So we have this use block. Trace, trace is related to capturing the screenshots on the browser when the test fails. We don't run browser, we don't run screenshots, we don't need it, it's irrelevant for us, removing. Base URL, you can use base URL in the API testing, but that's the only one value that can be used inside of the configuration file. And usually in API testing, you will have more than one API that you will interact with. So the approach that we are choosing right now with the api-test-config.ts, where we define the base URL over here, and then you can put multiple APIs that you will need to interact with is more convenient approach. So we will not use this base URL and we can remove it. So technically the use block becomes not needed in most of the cases. So there are just two things that are useful in the use block, couple of settings of the framework that you can use. First setting that I already mentioned is the extra HTTP headers. So if your framework has some headers that you want to define in advance and be passed to every API request, this is the place where you can define this. And the second thing, if your API has basic authorization, you have this HTTP credentials where you can provide the username with some value and password with some value. Again, basic HTTP authorization is a rare case when it used right now with the API. So most likely you will not gonna need it, but if you need it, you know that this option available in the playwright supported by the framework natively. One more thing about this use block. So this use block available in three different places, in the global framework level over here, in the project level, in the test level. So for example, if you want to define extra HTTP headers for the project, for specific project, but not for the entire framework, you can add this use block into the project level like this. And hold on like this. And it's gonna work. So the settings defined on the project level will override the settings defined on the framework level. And the next level, you can define this use block with those settings directly inside of the test, something like this. So I go to the test and I type test.use like this, and then put this object over here and I can put this HTTP credentials, for example, that way. So it's gonna work. So this HTTP credentials will override the project and global framework settings. So this is how you can configure it in case you need it. Our API is different. We don't need it whatsoever. So I just remove it. But you know that if you need, you can use this use block. So revert everything back, remove this as well. And I technically just keep the use block empty like this. Okay, now reporters. So currently we use two reporters, HTML and list reporters. If you need to add extra reporters for some reason, you can look at the list of the reporters available in documentation right here. So here we have dot reporter, blob reporter, JSON reporter. One reporter that might be useful is a JUnit reporter. So CICD systems has a very good integration with JUnit reporter. For example, Jenkins, Azure DevOps, CircleCI and so on. When you want to import your test report into this CI system. So JUnit reporter can be useful. As for me, HTML reporter works just fine because it has all needed steps and details and logs and stuff like that. So this is where you can configure additional reporters over here. Moving on, I remove this. So workers, we already talked about workers. I would recommend you to use a single worker all the time for API testing. You don't need anything else. This configuration currently either use one worker in CI or running locally, one worker as well. I remove it and just use one worker always by default like this. The next settings is retries. It's pretty useful settings. So if the test fail, Playwright will automatically retry this test one more time. So by default is configured to retry in CICD pipeline two times and when you run locally, just zero times. So without retry at all. If I change it to one and let me show you how that works. So if I run this test, run it one, no, it failed. Let me try to run it through the command line. So npx playwright test. How about the projects? Yeah, project should fail. Okay, it's smoke test. Running the test. Smoke, you see it made one retry. So I'm going back to this code and right here. See, so the test made one request, the request failed and retried it one more time. And when it retried the second time and it failed, then Playwright marked this test as failed. So pretty useful. If your tests are flaky, maybe this retry would be helpful. Other than that, keep it as zero to have your reporting more cleaner. So what is this? Fail the built-in CI if you S init left test only. Well, I will just remove it. We don't need it. So this one fully parallel. Let's keep this flag. Test directory is just, we define where the tests are located is under the test folder. And here we also have some of the settings related to configuration of environment variables through the .env file. And we will touch about this and talk about this a little bit later. So that's pretty much it guys. So we simplified our file by a lot, removed what is not needed. And this is what you need to keep for running your API test in Playwright configuration file. So as you can see, configuration is pretty minimalistic for API testing in the Playwright. The most useful use case is configuring the project depends on the scope of your testing. Other than that, it looks pretty simple. All right, that's it guys. And see you in the next lesson.