Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Make planId overridable #82

Open
Az8th opened this issue Oct 18, 2024 · 1 comment
Open

[Feature] Make planId overridable #82

Az8th opened this issue Oct 18, 2024 · 1 comment

Comments

@Az8th
Copy link

Az8th commented Oct 18, 2024

Hello,

I have several cases where I have to execute tests scattered through multiple tests plans.
A simple example : I update the POM & fixtures, so I perform a npx playwright test --only-changed that are used in several tests cases across multiple test plans & suites

Unfortunately I can't make use of the reporter in this case, but it could be solved by adding support for multiple planId, such as testPointMapper already does for configurations.

Another method that would ensure backwards compatibility, would be to keep the exisiting planId, and use it as the default one, but adding the capability to override it locally.

  • Either with title/tags , by adding a prefix separated with . (PlanId.CaseId) :
test('Test case A [42.12345]', async ({ page }) => {
  await expect(true).toBe(true);
});
test('Test case B', () => {
    tag: '@[42.12345]',
  }, async ({ page }) => {
  await expect(true).toBe(true);
});
  • Or annotations, by adding a new matcher :
test('Test case', { annotations: [{ type: 'TestSuite', description: '42' }, { type: 'TestCase', description: '12345' }] }, () => {
  expect(true).toBe(true);
});

Both methods may only be supported with publishTestResultsMode: 'testResult' though.

Would it be possible considering the actual architecture of the reporter ?

Thanks and have a nice day

@alexneo2003
Copy link
Owner

  1. If specs that you will run have include test cases from few different plans how you wish create test runs in ADO?
  2. If we would have few plans we should create test run for each plan
  3. If we would create few test runs we lost ability with AZURE_PW_TEST_RUN_ID and isExistingTestRun

...maybe I'll think of something else

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants