I work with Playwright, Mocha and Chai. In the application that I am currently testing I need to automate the following scenario.

When a user logs into the application a dashboard with assigned list of items is displayed. Each of the item has its own id displayed in a form of table. Each element can be deleted from user dashboard. Once it happens the item is removed from the dashboard and it lands on global dashboard view with a Deleted status.

Now I have two tests, 1st is in charge of deleting the item from the user's dashboard and making sure that it is no longer there. 2nd checks if the deleted item was moved to global dashboard and has correct Deleted status.

How can I pass the data from one test to another. The data that I am referring is the Id of the deleted item which is normally displayed on both dashboards.

  • 2
    Why do you need to? Your tests should be independent, is there another way you could establish the precondition (a deleted item exists) in the second test?
    – jonrsharpe
    Jul 22, 2021 at 10:30
  • @jonrsharpe I fully agree with the independent approach and that is how I usually handle it, however at this point I was just wondering what are possible solution to handle such a task. The only way that think I could establish the precondition is to use API and look for the ID of deleted item and then use it in the second test. However this might be limited because of my organization policy. Was wondering if there could by an workarounds. Jul 22, 2021 at 14:58

2 Answers 2


One test. Two setup steps.

What you have described is very common, particularly as test scenarios get more complex.

What you need is one test with setup that does the user logging in, the user selecting the item (save the id) and then deleted and then you go the dashboard.

So don't think in terms of your two existing tests, think in terms of a new test but with more setup steps.

This is frequently a case of 'sounds easy, but in practice...' and you will frequently run into issues about

  • authentication as different users and switching between them
  • storing authentication details
  • items ID's being dynamic and changing with each run

These can be difficult issues often involving organizational security and access issues. It's best to have a detailed discussion with the relevant folks in your organization so everyone understand the problem and is on-board with the solution. Be sure to involve application developers so their knowledge and skills help and also so that they are fully on-board with it and feel shared ownership. Include security folks as necessary or compliance folks may stop by to say hi.

In trying to achieve this you may indeed run into issues with 'organizational policy'. This is why you need the conversations. You need policy and implementations that achieve the business goals securely. In my experience, many organizations over 5-10 years old struggle with this, much more technical approach to QA and the engineering approaches and needs that it involves.

Longer term, having tests needing to use real authentication will be increasingly problemsome and this dependency needs to be removed. When there is an actual problem with authorization you want one, or at most a few, authorization tests to fail. The rests of the tests should be able to run with a mocked out authentication process, or at the very least, not run at all. Smoke tests can be very helpful here, for example testing that deployments havent broken authorization processes. Otherwise you will have hundreds or thounsands of tests failures when there is a problem with authorization.

  • Indeed, you are right as well as the answer above. I will take your points as notes and if I run into 'organizational policy' issues I will try to address them. Also I will try to approach the issues from different side as you wrote at the beginning. Jul 23, 2021 at 14:23

It's an single integration test.

First of all it has nothing to do with playwright, it's common automation scenario which can occur while using any automation library/frameworks. I have faced this similar scenario in qtp, selenium, protractor, and playwright .

Usually this will be an single integration test where we dynamically store ID on a test level variable before deleting on one screen and verify it on other after deletion.

Simplistic code example to show shared variable between specs:

 describe('some test', function(){
    let value = 0;
    it('should pass a value', function(){
        value = 5

    it('and then double it', function(){
        console.log(value * 2); // 10

If for some reason, you may have to implement it as two separate tests then one test can write the required info on shared data file( I prefer json files in JS world) where each test can access(read/write) it for precondition dynamic data as required.

  • You are right, it has nothing to do with the tool itself. It should be treated as more like an open question. I like your idea and I will try to implement it in my solution, however could be so kind and provide a simple code example of your suggestion? Thank you Jul 23, 2021 at 14:43
  • 1
    You are welcome! Added an simple example. Jul 26, 2021 at 19:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.