Issue 1:
System info

Playwright Version: [1.31.2]

Operating System: [Windows 11.]

Browser: [NA]

Other info: API testing Using Playwright

test("GET: Fetch Document Type Groups", async({request, baseURL})=>{

const response = await request.get(`${baseURL}/document-capture/document-type-groups`);
expect(response.status()).toBe(200);
const responsebody = await response.json();
const employeeDocuments = responsebody.data[1].id;
console.log(employeeDocuments);
**request.storageState.employeeDocuments = employeeDocuments;**
})
test("GET: Fetch Document Types for a DocumentTypeGroup", async({request,baseURL})=>{

const response = await request.get(`${baseURL}/document-capture/document-types`,{
params:{
**'documentTypeGroupId': request.storageState.employeeDocuments**
}
});
expect(response.status()).toBe(200);
const responsebody = await response.json();
const offerLetterDocTypeID = responsebody.data[2].id;
request.storageState.offerLetterDocTypeID =offerLetterDocTypeID;
const newHireCheckListDocTypeID = responsebody.data[1].id;
request.storageState.newHireCheckListDocTypeID = newHireCheckListDocTypeID;
})

Expected

IT should fetch the value from the previous request that is getting stored in the first call

Actual

I was trying to chain this two request by fetching a data from the response and storing in the storagestate (request.storageState.employeeDocuments = employeeDocuments;) , but when i am passing this in the query params of the second request, it is gettng passed as undefined

Issue 2:
Feature request

The purpose is testing of complete applications that have concepts like branch offices or clinics. More explained below.

The solution would be instead of from a directory listing to get tests from a JavaScript generator function https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators . One possible way to configure could be if project.config.testDir is a function instead of a string, but it could have its own name too. The entry point to start implementing apparently would be test/runner.ts but it would affect test/loader.ts. The functionality should be optional, only if such a function is provided. If used, it would imply less parallelism, limiting to one worker per project.

There are three items of functionalitiy. Currently we use very hacky workarounds. To understand the need:

A branch office or clinic needs to be set up. With proper authentication and verification, involving email, OAuth, etc., a staff memeber filling out information about themselves, etc. that process as a test case can take a minute per user (also for the clinic itself). Outside IT systems are involved for the authentication and verification, which take any number of seconds to process, sometimes half a minute. Not a problem, but it takes a while.

Those staff members need to exist and be used in further tests. Not just one, but different roles, for example a doctor versus a technician, but also with different access rights, admin versus regular user. Maybe a handful or a dozen users are needed, so that further tests then can determine that they cannot violate role specific limitations. E.g. a non-admin user must not be able to change anyone else's records, or a tech may not be allowed to sign a diagnosis like a doctor.

Therefore, executing tests in order is essential: A clinic must be created, professional users must be created, only then patients can be seen.

The creation of a clinic and of professional users itself are distinct test cases. They are part of the system and as such deserved to be implemented as test cases. It makes little sense to duplicate that ability some other way. That reinforces the idea that executing tests in order is essential.

As a side note, it would be nice after creating a set of users, then to run some code that isn't test code proper, but that sets up "from now on use the users that have been created". This does matter for the idea of execution in time: If the test running mechanism comes back to the generator function after each test, that allows the generator function to have additional code in it, that "knows" after all users have been generated, to set something up for the following tests. That step of setting up wouldn't work if the test running mechanism ahead of time asks for all tests to run. (Workaround for this one requirement: Make and insert in order a fake test that does those intermediate setup steps.)

The next topic: If you need ten users, maybe that would be ten times the same test case "register-a-new-user.test.ts". The generator function could ten times give the same script to run. That works better if the test running mechanism comes back with next() after each test and the generator function gives it the same test file name to run again next. Each test run would be somewhat different with random or seed data.

There is more about randomization, but to keep it short, we can describe: Running the same test case any number, three times, twenty time, a hundred times, is very valuable to what we have been doing. Specifically there is a lengthy form, that takes half a minute or a minute to fill out, in part because of API calls to the server, not useless waiting, not lack of skill in test writing, just a lengthy form. Imagine patient intake, health history, or imagine a complete tax form (which are longer for people with family or a business). The point is: A hundred or even ten or three of those, do not reasonably fit into a single test. And, because of the many possible combinations of data (age, history, symptoms, etc.) randomization is a significant feature to actually achieve quality.

Therefore, the abilitiy to run the same test file multiple times, any number of repetions as seen fit that time (for example quick acceptance versus a broader sweep) is important. (Difficult workaround: Symlinks. Not how it should be. Parallelism, cleanup, naming, etc..)

It is important to do this within a test run, in order to have reporting. We have so far done some of this with scripting outside loops, invoking Playwright for each repetition, but that means there isn't a singular final report.

Notably, a generator function can be invoked multiple times, also in parallel, e.g. if testing Chromium, Firefox, WebKit.

Related could be #7028 and maybe #7050 .