Managing Request Payload | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: Test Management
Instructor: Artem Bondar
Lesson Summary
In this lesson, we discuss how to organize request payloads for API testing. The focus is on improving readability and maintainability of large JSON objects used in API requests. Key Concepts Current Approach: Previously, JSON objects were directly included in the body of the request, which is manageable for small objects but becomes unwieldy for larger ones. Vertical Formatting: Formatting JSON objects vertically enhances readability, especially when dealing with objects that have many properties. Reusability: If the same object is used multiple times (e.g., create, update, delete operations), it is better to define it once and reference it throughout the tests. Organizing JSON Objects To manage request payloads effectively: Create a dedicated folder for request objects in your project structure. Store JSON files (e.g., postarticle.json ) in this folder. Import the JSON object into your test files for use. Modifying Request Payloads When you need to change specific properties (like the title), override them in your test: articleRequestPayload.article.title = "New Title"; Concurrency Considerations When running tests in parallel, avoid modifying the original object directly to prevent concurrency issues. Instead, create a new instance of the object: const articleRequest = JSON.parse(JSON.stringify(articleRequestPayload)); This method breaks the reference to the original object, allowing safe modifications without affecting other tests. By following these practices, you can ensure your API tests are organized, maintainable, and capable of running efficiently.
Video Transcript
Hey guys, and we are moving on and in this lesson we're going to talk about how to organize request payloads for your API test, all right? Let's jump into it. So previously in the SmogTest.spec.ts, for the post request, we were using the objects directly inside of the body method right here. And we provided the entire object as a single line. But imagine if your real API request in the real applications will be bigger. What are you going to do next? So in this case, you will need to write the long line that will not even fit the screen. And the real API request in the real applications may have like 20, 30 properties. Our current object have just five properties and it is all right keeping it like that. But with the bigger objects, it will be more challenging to keep them organized. And actually, the JSON objects is more convenient to keep formatted vertically like that. So it will be easier to read the object, which properties it have and what those properties do. And I command shift F and I am formatted the script. Right now you can read the object like more conveniently. We have articles and then articles has few properties. But again, imagine if you have a bigger object, you need to paste the object inside of the body with like 20, 30 properties. And then you will have this giant object inside of the test, which will make reading the test harder. And one more thing, imagine that you need to use this object several time in your test. And we already using this object several time in the test here in create, update and delete article. So we will use exactly the same object again and again to create the article and then to update the article. We only change the title for the object. The rest of the properties are the same. And this is one more point about the request payload. Normally, during the API test, you will use just a few properties that you might need to modify or change to make an API request. The rest of the properties can be kept just with the default values. You don't care about those. So you don't need to keep those redundant and not needed properties directly in the test. You can save it somewhere in the different place and let it sit there in case you need to come back, change it, modify or something somewhere in more convenient place. So to manage the request payloads, it's better to keep the JSON object, especially if it's big JSON object separately in your folder structure. And the best way would be just to create a folder and keep those JSON files over there. So let's do this. So we have currently response schemas folder and let's create similar folder and we will name it a new folder. Let's say request objects like this. And in the request objects, we're going to put our JSON objects. So it depends on your project and on your needs. If you have a lot of requests that you need to make, maybe you can keep the folder structure similarly like we have for response schemas. For example, for the articles objects, you create the articles folder. For the text objects, you create the text folder and keep your objects like that. If you don't have a lot of request objects like we have for our project, we can just keep it simple. And then inside of this folder, I just create a new file and I will call it postarticle.json like this. And I will copy this object over there. Ctrl C, Ctrl V, Command Shift F, Reformat. And now I just import this JSON object inside of the file. So like here, import, and this is post. Let's call it articleRequestPayload something like this. And we import it from new folder request objects and the file postarticle.json, that's it. Now we can use this payload directly inside of the test right here. I just paste it right here. And our test now looks much nicer and very organized. So if I run it, it should work. Let's run this test and test pass successfully. But let's say that you need to update or control some properties of your object. For example, currently we have a validation that the article should have test to test title, okay? And currently this value is hardcoded over here. But let's say you need to use this object in several places. So you need to provide different title for the different test. So you can override the needed properties for this object inside of your test and so update their request payload. So the good way would be to do something like this. Before the place where you want to use this object, you just call this objectArticlesRequestPayload.article. And we want to change the title equals to, and then we put any title that we want. This is an object title, something like this. And now this value will be replaced with this title. So then we can change the validation right here, right here, and right here. And I'm running this test one more time, and test pass successfully. So right now our test was using this object, but we overrided the title instead of this value. We overrided to a new test value, and this value was used to perform API request right here. Now here is one important note about this approach. So look, if we're gonna use the same object right here. So if I take this article request payload and replace in the test over here like this. So if I'm gonna do this way, since we are overriding over here the value of the title of the original object. And we are referencing to the original object that we imported from the JSON file. So if you will run your test in parallel, and the test create and delete article will be executed together with the test create, update and delete article. And this post request will be executed at exactly the same moment as this post request, there is a high chance that the value that you set for the title in the test number one will be exactly the same in the test number two. Why? Because we are here changing the value inside of the object referenced on the test spec level. So we imported the object, overrided it, and the entire object will be used everywhere where it's called inside of the test. So that's kind of a trade off with this approach. But what you can do, if you still need to run tests in parallel, but in API testing I mentioned, most likely you need to run just test sequentially. If you run the test sequentially without parallel execution, you're gonna be just fine. But if you have a lot of tests and you need to run two, three parallel threads, just to make sure you need to break this dependency on the original object. So you need to import this object kind of independently into every test. That way, when tests will run in parallel, you will not have any concurrency issues. So how to do that? For that, you need to create a new constant. And let's say we call it, I don't know, articleRequest equals to. And then we need to stringify and parse our JSON object. So that way, we will break the reference dependency on the original object. So first, we call JSON.parse. And then inside of it, we called JSON.stringify. And then property for JSON.stringify will be this original object like this. And then we update this object and use it inside of the payload. That's it. So using this type of structure, we called our original object. We stringified, we converted the object back to the string. Then from string, we parsed it back to the object. And that way, we broke that dependency to the original object. Now this articleRequest constant represent the instance of the object that does not have any relation to the original one, to this guy. So and then we can modify it however we want. And we will make sure that way that we're not gonna have any concurrency issues. So just keep this in mind, okay? And that's pretty much it. That's how you organize your request payloads. Just organize them nicely in the folders like request objects. Put them additional folders if you need. Call the JSON files inside of the test. Update the properties that you need. And that way, you can run your test. If you want to run your test in parallel, don't forget to use this JSON parse, JSON stringify. Make sure you break the dependency on the initial reference to original object. All right, that's it guys, and see you in the next lesson.