Updating the Playwright config

- [Instructor] Now that we have Playwright installed, we will be taking some time to work on our configuration for our project. We're going to spend this lesson reviewing the playwright.config.ts file. Let's go ahead and open that up in VS Code and take a look. The first thing to note is this file was automatically generated when we ran the playwright init command. Inspecting the file, we can see the main method is actually defineConfig. With this, there are different levels and options available. The top most level is where a lot of the Playwright test runner options are found. Within the main test runner config, let's break down a few of what these options are doing. Starting with fullyParallel, which is set to true. This option allows multiple test files to be run in parallel. More details can be found in the docs provided in this hover over section. Another important section is the retries option. Playwright gives us the ability to assign how many retries we want to attempt based on the values we add for retries. As you can see, the default value is process.env.CI with a question mark, with a two, a colon, and a zero. This is a conditional. It's actually a ternary operator. It's basically telling us that if process.env.ci, when it's evaluated, if it's true, it's going to use the first value, two. If it's false, it's going to use the second value, zero. By default, anything run in a CI environment such as GitHub Actions with that environment variable set, we'll have two retry attempts, but anything run on a local machine will have zero retry attempts. Let's go ahead and refactor this to have one retry when we're running on our local machine from changing the value from a zero to a one. Let's also go ahead and update the text. Retry on CI two times and locally one time. You can see that the workers option has a similar value with a ternary operator. Having a programmable configuration file is really helpful in that we can add creative logic to open a ton of other configuration possibilities. A list of different options on this level can be found within the Playwright docs under the testconfig class. We also have reporters. HTML is by default. We're not going to dive into that here, but we will in a later video. There are some default timeouts in Playwright that aren't listed in the config that I find it useful to go ahead and add to the config so I know what to expect and make them easy to change in the future. So at the top of our defineConfig, let's go ahead and add a new line, and let's type in timeout:, and I'm going to type in 30_000. This is indicating 30 seconds or 30,000 milliseconds. So this is the test timeout. If 30 seconds goes by and the test is not complete, the test will fail. There's also a globalTimeout. Let's type that, globalTimeout, and we're going to set that to 10 minutes. This is some other syntax you can use. So we're saying 10 minutes or 10 * 60 * 1000. This is just another way to visualize 10 minutes in the config file. This config says if all of your tests take longer than 10 minutes to run, your Playwright test will fail. So if you have a longer test suite, or as your test suite grows, you may have to increase this timeout. The use section down below here is really where we get into the nitty gritty details of the browser, the browser configuration settings, and how the browser is going to interact when running test. I'll go ahead and mention, even though we're not going to dive into this now, there's another section called projects below. The projects section also has a use section. The use on the highest level underneath the defineConfig where we're looking now is the overall default that is set, but on an individual project level, you can override these settings. You can even do it on the test level by calling test.use. Let's go ahead and add a few things to the use section that will be useful for us. So let's start by adding actionTimeout: 0. (keyboard clacking) I'm going to hit comma, I'm also going to add ignoreHTTPSErrors, we're going to set that to true. And I'm a big fan of enabling traces to always be on by default is set on-first-retry. You know, if I hover over this, I can see the different options. I'm going to just set this to on, so I'm going to update this config. The trace file is going to include things like network request, console error logs, and all sorts of different elements on the screen along with a timeline view of the how that happened. We'll look into that deeper in a future video. I also like to set a video to retain on failure, so let's add that in here, video: 'retain-on-failure'. Let's also add that for screenshot as well, screenshot: 'only-on-failure'. Let's also go ahead and add headless, and we're going to set this to true. This is the default. I don't want my browser popping up and interrupting my flow when I want to run a test from my command line. There are ways to enable this through the CLI, which we'll look at a little later, but it's always best to set this as true. The last thing we're going to look at is this baseURL. It's currently already set here, but it's commented out. So we're going to uncomment this, and we're going to update this to our test website. That's going to be https://practicesoftwaretesting.com. This baseURL is unique in that it allows you to set a URL. It's a base, so you can have your own .com or io or .net domain. You can also use a variable here in this config file if you wanted to use that and override that based on other configs. By default, this baseURL is available in your test. By default, it's going to attempt to use this first. So you can pass things like page.goto and just pass in /login instead of the full URL, and it will go to this full URL /login for you. This is really useful as we're setting up our test, and you'll see this use later. There are also lower level config options in use, such as web server and different expect things that you can read about in the official Playwright docs.