Playwright Workers | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: Building a Framework
Instructor: Artem Bondar
Lesson Summary
In this lesson, we explore the concept of workers in Playwright, which are essential for running tests efficiently. A worker is essentially a process that executes your tests, similar to a single thread or executor. Key Concepts of Workers Single Worker: Executes tests sequentially. Multiple Workers: Created to run tests in parallel, enhancing performance. Configuration Settings In the playwright.config.ts file, two important settings govern worker behavior: fullyParallel: When set to false , tests within a spec file run sequentially. If set to true , tests can run in parallel. workers: Defines the number of workers. If set to undefined , Playwright will use half of the available CPU cores. For example, a MacBook Pro with an M1 chip (10 cores) will utilize up to 5 workers. Running Tests When running tests: With fullyParallel: false and workers: undefined , tests execute sequentially within each spec file. Setting fullyParallel: true allows tests to run concurrently, increasing execution speed. Using a single worker means tests will always run sequentially, regardless of the fullyParallel setting. Worker Lifecycle When a test fails, Playwright reinitializes the worker to ensure a clean environment for subsequent tests. This is crucial for maintaining test reliability. For API testing , it is recommended to use a single worker to avoid flakiness caused by parallel execution, as API tests are generally faster than UI tests. In the next lesson, we will delve deeper into managing user authorization using workers.
Video Transcript
Alright guys, in this lesson we have a little break, we're not gonna write any code, but instead I will explain you one important concept about the playwright, which is workers. So a worker is the process in the playwright that runs your test. So single worker, think about it as a single thread or single executor. And if you want to run your test in parallel, then several workers are created to run your test in parallel. So each worker is, think about it, an independent process to run your test. Let me show you how workers are configured and how they work in the playwright. Alright, so this is the playwright.config.ts and when we talk about workers we are interested in these two settings, fully parallel false and these settings of workers. So let me start first with a fully parallel false. So fully parallel is a flag that defines do you want to run your test in parallel within a spec file or not. So if we have fully parallel false it means that playwright will run the test within a spec file sequentially one by one. But if you have several spec files like we have spec 1 and spec 2, playwright by default will run those tests in parallel. If we have workers configured to do so and this is when we go to the second settings of workers. So workers is the place where you define how many workers do you want playwright to use. By default we have an option like this. So process if the CI process environment variable was set then just a single worker to use. Otherwise if you run on your computer undefined. So playwright recommends to run in CI CD use just single worker just for their stability. But if you run on your own computer of course it's going to be faster. And undefined what does that mean and how playwright will define how many workers to dispatch. So if the settings is undefined playwright will look into how many core CPUs do you have. For example I have MacBook Pro with M1 chip. This chip has 10 cores in this CPU. So playwright will take half of those CPUs. So up to 5 workers will be created and up to 5 parallel threads will be executed. This is how it works. If you want to run your test only sequentially without any parallel whatsoever you need to change the settings from undefined to just one. So playwright always will use just a single worker. And let me demonstrate that a little bit right now. So currently we have fully parallel false and undefined. And we have two spec files. If I try to run NPX playwright test and run the test. And tests are executed. Something is failed. This is expected in the parallel execution unfortunately. And by the way we can look why is it failed. And we have okay we have 500 error. Something invalid. Prisma article creates. You see some server-side error created. And by the way this is why logging is so useful. Now you know you have this error message that you can give to developers and say hey we have 500 error on our API. Check it out. But we are not looking into this stuff. Look into the logs. So going back to terminal I scroll all the way up. And here running eight tests using two workers. So we have total eight tests. Four tests in the example spec.ts and four tests in smoke test that spec.ts. We have undefined workers but fully parallel false. It means that test within the spec file executed sequentially. So playwright created only two workers executing test in parallel using two threads. So now let's create some I don't know madness and try to run this test using maximum number of workers for our computer. I check okay the article is created. Clean this up. And now I change fully parallel to true like this and try to run this test one more time. And now what playwright gonna do. Now you already see. So yeah of course some tests are failed again. That's expected. So I'm scrolling up and running eight tests using five workers. So five parallel threads were created and tests were executed that way. And the last option. So let me fix this. Do we have any articles? Yeah we need to remove this. I removing this stuff. And then I change the configuration to use just a single worker. With a single worker it doesn't matter. Do you have fully parallel true or false. It doesn't matter at this point because only single worker will be used and it will execute test one by one. So run the test now. And now it should pass because we should not have any interference with the test data or articles or something like this. So running the test. And you see tests are executed exactly one by one. And also tests are executed in order how they are placed inside of the framework under the test folder. So first as example spec.ts then smoke test.spec.ts. You can see here it's exactly in the same order. First this file and then test one by one were executed. And the second file and so on. And I want to show you one more feature about the workers. So when worker is created and recreated. So by default when you trigger the framework execution Playwright creates a worker and use this worker to run all the tests until the test fails. And when the test fails just as a safety measure Playwright re-initiate the entire framework again creating you a completely fresh version of the worker and continue running the test from the place where it left off from the previous failure. So let me show you this example as well. So I go to smoke test.ts and let's say that we want to fail the test number three. For example, where do you want to fail it? On some assertion. I don't know. Let's say we're gonna do it right here. So after the assertion the test number three should fail. And now I will run this test. Let's see what's gonna happen. So we run a single worker with a third test to fail. So we run the test. First is example-spec.ts. Then it's running again and okay test failed. Going back to the logs. So we are looking into the sequence of execution. Look. So first we had example-spec.ts. We skip that because this is the simple configuration that we're not used which is not using our fixtures and all that fancy configuration that we created. Now look over here. So before it started running smoke test.spec.ts it's initialized all the configuration related to this setup for this smoke test.spec.ts and it's called the configuration file which is this one api-test-config and this line of code was executed. Then it run test number one, test number two, test number three. Test number three failed and then Playwright created a new worker and loaded entire framework again running all the configuration and dependencies that it has and that's why we see this line over here triggered again because this api-config file was reloaded just in case to make sure that we have a clean and pristine version of the executor making sure that you know it's not the false of the framework it's the false of the test why the test failed. So this is how Playwright works, how parallel execution works, how worker is created, how you can control the workers and for API testing I would recommend you always use just a single worker so parallel execution makes sense for UI testing because UI test just naturally significantly slower. API tests way way faster so it's rarely when you need to use parallel execution for API testing but parallel execution can pretty often be a reason of flakiness because of different data data set issues and stuff like that and in the next lecture we're going to use this feature of worker how Playwright creates worker dispose workers and all that stuff to manage user authorization alright so see you in the next lesson