Data creation and deletion for happy path automation

Question

Hypothetically, if an automation engineer had to write a test for commenting on a post in a group on Facebook and did not have direct access to the db, but instead to the rest api, the automated test would need:

1. A user
2. A group
3. A post in the group

Since a test should not depend on data from previous tests, should this test create a group, then create a post and then create a comment on the post? Should the same test then delete the comment, delete the post, and delete the group? There are lots of points for potential failures here. What are some best practices for getting an application into the state necessary to perform an atomic automated test? Create and delete the data via the API as part of the test setup and teardown? Something else?

Answer 1

So, here is what we do in such scenarios:

You are right. Test should not depend on data from previous test. But still, you can have test data created for tests and that data can be used repeatedly.

For example, in this case, we will create dependent data manually. It's a one time activity. So, we have an existing user and an existing group and an existing post.

As part of the test:

• User will log in

• Add a comment to the post in the group

• Validate the user was able to comment successfully

As part of the teardown, delete the comment (from UI or api, whatever works). Your test can execute any number of times, with the pre-requisite data you created once.

That's it.

Why we take this approach?

• We don't want to have too many pre-requisites.

• It will increase the test execution time significantly.

• Moreover, if the api endpoint to create user/group is down, your test won't be executed.

We have many scenarios where we do things as part of pre-requisites, for example, creating users etc..but we try to keep it to a minimum.

We have tried different things; as you said, creating all the dependent data before the test execution and then cleaning everything after the test execution completes. But, we found the above approach as the simplest with practically no overheads.