Closed itz4blitz closed 1 year ago
I have not looked into that, but will test it out when i have some time and get back to you
Hi @denisha
Can you provide a summary of your use case i.e. the intention behind using a case id in the test.describe instead of on the test level
In some of our test files, we need to use multiple storageState.json files in Playwright. We've found that when we primarily need a single storage state, it's cleaner to use test.use({ storageState: './path/to/auth.json' })
in our Playwright test instead of using a browser fixture and creating a new context, applying a storage state to the browser, and then creating a page. However, if we don't use test.describe to surround our tests that require this specific storage state, we're restricted to using either the browser approach or using test.use() only once for all tests in the file.
As a result, we organize our test files with a few tests inside a test.describe block and each test.describe has its own test.use() with a storage state applied for the tests within. This way, we can use different storage states for different tests without cluttering the code with unnecessary context creation.
What configuration are you using for your project on TestRail?
I'm not an admin in our Test Rail tenant, so I could be wrong, but I believe we use the single repository for all cases.
I did want to mention, so far this npm package is working great for our team. We've been able to create runs and better track the status of our automated tests, so thank you for your work!
Does mapping work with test.describe? We have several test files with test describes added so they can utilize different storage states without having to create a new browser context and storage state inside of the test itself. Would mapping still work in this example?