Parametrized tests having [whitespace] character in its parameter value are not properly registered in test run

[mrogachenko-cg]

Describe the bug When parametrized test have a parameter value with whitespace (e.g. "some value") are registered in test run, all of them are grouped as the same test with 'retry', while it is expected to be registered as separate test (separate execution line).

Prerequisites

• playwright project is properly configured to pass result into testomat
• tests are properly synced
• testrun is properly prepared and used for syncing result

To Reproduce Steps to reproduce the behavior:

1. Use the following parametrized test as example (replace test case id with an actual for your project)

let valuesList3: string[] = [
	'NoSpaces',
	"Under_score",
	'I have a space',
	'Me too have a space'
];

for (const value of valuesList3) {
	test(`This is an example of parametrized test with ${value} that could have spaces @T1d3b757f`, async ({
		page,
	}) => {
    await page.goto('https://playwright.dev/');
    await page.waitForTimeout(100);
    // Expect a title "to contain" a substring.
    await expect(page).toHaveTitle(/Playwright/);
	});
}

2. Run tests in a way that will sync result into prepared test run report (from prerequisites)
3. Wait until test are finished
4. Check the testomat's test run report

Expected behavior Each test execution should be registered as separate run

Actual behavior For single word parameter it is working as expected, for multy-word parameter it is registered as 'retry' for the same test with 'empty' parameters value

Screenshots

Additional context Probably another characters (not only [whitespace] may trigger the same problem)

[DavertMik]

Known issue.

We can't detect that multi-word parameter matches the test, so let's say if we have two tests:

• User clicks link to login
• User #{param}

If we allow param to contain whitespaces, receiving report for User clicks link to login we can match User #{param} instead.

This is why we would like to ask to use camelCase or underscore_case (underscore chars are ok as params).

[ghost]

@DavertMik I'm sorry, it's not quite clear why you need to detect test case matching by multi-word parameters instead of matching it by provided test case id? Not sure that current issue is the same you've mentioning.

[TetianaKhomenko]

re-opened per user request

[TetianaKhomenko]

@DavertMik

[DavertMik]

@mrogachenko-cg Hi, this feature implemented and already live on production Please check it

@TetianaKhomenko already on app.testomat.io

[ghost]

@DavertMik Hi Yes, it is working now