Playwright Configuration

[00:00:00]
>> I do wanna kind of just do a quick tour of a few things here as well. The one thing that for one of these example apps, there is a database that you need. So if we choose to use that one, you will just have to seed the database because I decided to be a back-end engineer for a hot minute, just to show some stuff, but that's there as well.

[00:00:21]
But the part that I wanted to go into was this Playwright configuration, where a lot of things are configurable. If you wanted to make an e2e directory, which I don't like acronyms, you'll notice if you read like the copious notes that I wrote. I will spell out Visual Studio Code every time instead of writing VS Code.

[00:00:39]
You can set the timeout for both a test as well as for a given expect. Fully parallel will mean that it will spin up, depending on how many cores in your computer, that many threads running in a browser. Most CICD processes I think you're still down to one.

[00:00:57]
It'll try twice in CICD before failing your build 0 if you're developing, so you get that tighter feedback loop, but hopefully protection against flaky tests. How many workers do you have? The reporter, we saw the HTML. We'll play around with some stuff in here a little bit. This one is probably the one you'll most likely end up using, which is this way, you don't have to type in a full URL.

[00:01:19]
If you don't put the protocol, it'll assume this, change that to whatever you use. You can do interesting things with environment variables, so you could do something like, hey, do this and last like, we're in, like the CICD process or unless like I choose targeting and staging. One of the things that I have done previously, is I will have the base URL for my app as an environment variable.

[00:01:47]
So I can point the development server and its APIs at mocks or I can point it at production, right? Because every back-end team likes to tell you that staging should be a perfect representation of production that has never been the case ever. So I can point my front-end app at staging, at production, at development.

[00:02:08]
So you might choose to do something there as well. If you don't want all the browsers, a project and just do dash project chromium, it will run all of them. You can do interesting things here as well, which is like what tests you wanna run. Also like various different, this way, you're not doing the thing.

[00:02:27]
I understand that the browser has all the device emulators. We all do the same thing, which is we make our window real skinny, right? And then, we make it wide again, and then we make it skinny, and then we make it wide, right? This will run your tests, saving you from that.

[00:02:42]
This one will also be somewhat useful to us, which is folder for test artifacts. Right, if only I had a way to store my artifacts, my build process, I could look at them later. This one, I also deeply love and we'll probably just comment out. It does not work with the VS Code plugin, but this one when you run the test, will also spin up your server too.

[00:03:11]
Because nobody likes the thing where you go to run the test and realize that they killed off the server, and then your tests all fail. And then, you realize that you testes didn't fail, the server just wasn't running. So you can have it like whatever your whatever port you choose run on, whatever command it takes to spin up your app, you can have it so that when you do npx playwright test, it will also spin up your web server and life will be amazing.