Passing the UI data from one test to another

Question

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.

Answer 1

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.

Answer 2

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.