API Testing With Katalon Studio: The Basics

Hello and welcome to Katalon API testing tutorial. So in this tutorial, we'll continue our journey for the API automation using Katalon Studio and now once we have installed Katalon Studio, we'll explore a bit about the interface of Katalon. And then we'll also do our first request or trigger our first request in Katalan Studio. So this will be our REST API at this time. So I'll be taking a sample REST API and trigger first REST API, get request, and see how you can do it in Katalon.

Now once you launch Katalan Studio, you will see the menu bar at the top. So, 'File' to create a new sample project or new project or open the project. Then, you have some certain options for the action. This is more, you know, like for the API web service. You can create 'Open rest' or 'SOAP request' or you can import WSDL or Swaggart from this action menu.

And then you can have the 'Edit' options there, 'Project', 'Debug', 'TestOps'. So, I'll cover these menu icons or the details of the menu once we get into the details and as when required, we'll cover the details of these menu items later.

Then you have the important aspect of the UI is the 'Test Explorer' where you will find that you can create a new project and all the project details will be displayed in the Test Explorer in the tree format. Then, on the right-hand side, this is a bigger section where you have the Katalon Help. This is the request editor. So, you'll be able to form the request and select different methods.

So once we create a project, you will be able to see a lot of details that will be displayed in this section here in the request editor. And because this is the Katalon Help, you can get a lot of help around web UI testing or API testing. So if you go to API, you will see the step-by-step details of how you can trigger your first request in Katalon. So we'll cover these steps as part of this tutorial itself.

Now, in the extreme right-hand corner, you will see this is more of a debugging and console log section here. So you can open the console and then event log, etc. And then at the top, you have the debug option and then you can change or work for your profile, with your profile, open the dashboard, etc. So, these are some of the common key sections. So, the menu bar at the top, 'Test Explorer' and the request builder in the middle here, and the console and debug log in the section in the extreme right here.

So, now let's go ahead and create the first project in Katalon. To create the first project, we'll simply either go to the 'File' and click on 'New' and 'Project' or in the 'Test Explorer' itself, click on 'New project' and it will open the window for creating a new project. So, I'll say 'RCV', just provide the name of the project and then you need to select the type of the project. So, because we are doing the API testing with Katalon, I will select the API web service.

And in the project, you have the demo sample project as well. If you want to explore, you can choose that. We'll leave it as blank. And if you want to have the repository, so for example you want to check in your code to get, you provide the detailed repository URL there. But as of now, we won't be doing that initially, so we'll just leave it as blank. And by default, 'Generate .gitignore' and 'Build.gradle file' are checked, so just leave it as checked there. Provide the description of the project if you're right. So I'll just copy the name of the project and click 'OK'.

So now you will see that the project is getting created and once the project has been created, we'll start importing our REST API. So, now you can see the project has been created and we will close this Katalon TestOps integration. So this is a message, 'you currently have no teams to work on, please contact'. Just don't bother about this one. We'll close it and now we are on the project page.

So now, you can see, if you see here, so we have the 'Test cases', the 'Object repository' and 'Test Suites'. Alright, so these are the three key folders when we are working with the API. And then you have the 'Data file', 'Keywords', 'Listeners', etc. So we'll cover that later. So as of now, in order to start with your first request, what you can do is you can simply click on this little icon here.

So you can see it says 'New draft REST request'. So I'll click on that and it will open the draft request where we need to paste the URL. OK, so now it has opened the request, we'll go to the https://deckofcardsapi.com/, copy the location and come back to the Katalon Studio and paste the URL. So that we have copied from 'Deck of cards API', here you will see this drop-down here which is the method drop-down. So this is a GET request that we are triggering. We'll select the GET request and provided the detail of the shuffle deck API.

And then, as you can see, just after the question mark, it automatically detects the query parameters and populated the query parameters there, right. So in the REST API, the key thing to remember is that you have the endpoint which is https://deckofcardsapi.com/ and then anything after the slash is your resource, so api/deck/new/shuffle/ is the resource. And anything starting after the question mark is your query parameters.

Right, so for example, you are doing a query on Google.com, you are opening the Google.com website and then typing in the query parameters whatever text you want to search on Google.com. So basically anything in the web service or the REST API which starts after the question mark is the query parameters. Right, so if you would have Google.com, say for example if I replace this with Google.com, then the query parameter would be 'q=' and you can type in any text right. So that will be the query parameter.

And if you update these query parameters in the link, it will automatically update the query parameters in the section below here. Right, so I will just remove that. Okay, so now we have got the GET request, the method, we have the URL and the query parameters have been automatically populated in the query parameters section.

Now below this request, you will see the 'Authorization' header here, then you have 'HTTP' header, 'HTTP body', 'Verification', all the other details. Authorization is required in the case your API requires authorization and you cannot hit it directly or anyone cannot hit that particular API unless you are registered authorized to hit that particular API.

Then at the bottom, you have the 'Problems', 'Event log', 'Console', 'Log viewer' which is similar to the Eclipse. And then you have in the 'Response' section, you have the formatter. So you have the 'Body', 'Header', and 'Verification log' sections here. And here, at the bottom, you can select the formatting whether the response is in the JSON, XML, HTML, you can select the formatting options in the right-hand section here.

So as you can see, this is the query builder, and the log viewer, and the response which is all available in this particular section. So now in the request history, all the history will be logged for the requests that you are triggering from Katalon Studio. So if we now want to run this particular GET request, you simply click on this little icon 'Test Request' and it will prompt, 'Do you want to save the changes?'

I'll say OK and then it will hit or send this particular request and you should get a response. Right, so now you can see status '200 OK', the time it took, and the size of this particular response. And the format, automatically it detects that it's a JSON format and it has formatted it in 'pretty' format and chosen the formatting as JSON. Right, so that's all about triggering your first GET request from Katalon Studio.

Hello and welcome to Katalon API tutorial. In the last tutorial, we have seen how to trigger the first GET request for the REST web service. Now in this tutorial, we'll look into how to trigger the first request or the SOAP request through Katalon Studio. Now before getting into the SOAP request, we'll also try to understand about the 'Object Repository', 'Test Cases', and 'Test Suites.'

Now in the request history, if we see, we have triggered the GET request for a 'Deck of Cards' shuffle deck. Now, this has been saved as a draft but you can save this request as the name of the request or whatever name you want to provide. So, I'll say 'Shuffle Cards' because that's what this request is doing. And then it's in the folder Object Repository. You can save this particular request or web service request name and then you can utilize it later into your test cases and test suites. So, it's a good idea to provide the name and the description and then click on OK.

So, we'll provide the description and then you can see in the 'Object Repository,' you have the 'Shuffle Cards' GET request already saved. Now, this is helpful because once you are doing the testing or preparing a test case in a test suite, then you will be requiring an N number of different methods for the API that you are going to trigger. So, it's a good idea to save those operations along with the different methods and then reuse them in your test cases and test suites. So, we'll look into that later.

Now, this was our first GET request for the REST API. Let's see how you can trigger your first request for the SOAP web service. So this is the REST icon, so you can draft new REST request. And this is for the Swagger. And for the SOAP, you can draft new SOAP request. Or you can import the WSDL from File. So, we'll click on the WSDL and then we'll go to the link of the online calculator. This is the free web service that we'll be using for the demo purpose for the SOAP request.

So if you see the documentation, here, the following operations are supported. So it will support add, divide, multiply, and subtract for the two integers, which is pretty basic calculator web service. We'll go to the service description here on the link. And you can copy the WSDL link from here and paste the URL, click OK. Once you click OK in Katalan Studio, it will start the import of those operations. And once the operations are finished, you will see in the object repository, automatically it has created two folders with SOAP, which is SOAP 1.1 protocol and then 1.2.

So it created the operations or the methods for add, divide, multiply, subtract for SOAP 1 and SOAP 1.2. And now, you can reuse these methods accordingly in your test cases and test suites. So let's trigger our first SOAP request. So, we'll open the Add request. Okay, you double-click on the 'Add' and it will open the details. So here in the drop-down, it's showing as SOAP and SOAP 1.2.

Because it's a SOAP request for version 1, I'll select 'SOAP' and then in the 'Service Function', you can click on 'Load from WSDL' and load the detail from the WSDL itself. Now, in the SOAP request, because this is the Add request, we need to provide the details. So, we need to provide the values in the request as well. So, to provide the value, you just go to the 'Request Message'. This request doesn't need any authorization, so you can just leave it as it is. And then go to the 'Request Message' and here you will see that this is the XML file.

This is the XML payload where we need to provide the values of two integers, A and B. And then if we provide these values, then send this request, we'll get a response whether the request has been successful or not and the result in the 'Response'. So this is the Add request, it should return '8' as a response as an XML file. So once you have done these changes, that's all you need.

Click on this little icon, 'Run' icon. And it will ask, ''Do you want to save the changes?''. We'll say okay and it will start running the request and you will see the response with the result '8' has been displayed. So this is pretty formatted and this is the XML format that has been written. And at the top in the response, you will see that you have the '200 OK', which is the successful message. We'll go back, so this is the successful message from the server and then what time it took and the size of this particular response.

So in the REST API, in the 'Response', you can have the XML or the JSON. However, in this case of SOAP, it will always be in the form of XML. So, the response will be always in the form of XML. So that is why here you see this is XML response that we have got in the SOAP response. So this is how you trigger your first SOAP request in Katalon Studio.

Hello and welcome to Katalon API testing tutorial. In this tutorial, we are going to understand how we will configure the personal access token that we have created in the last tutorial in the Katalon Studio API. So, before we go ahead and figure out which request we are going to trigger, let's go to the Asana developers page and see which is the documentation that is present on the developers page.

So to go to developers page, let's go to http://developers.asana.com and you'll be redirected to the developers page. And here, you will find all the information about the authentication, the basics, what all APIs are supported, all the API references. On the left-hand side, if you see the menu, you start with the basics and then in the authentication-based basics, you will see OAuth 2 is required for the applications to access any of the Asana API and that's why we had gone through in the Asana developer console for the app console and created a personal access token that we'll be utilizing.

Okay so now, I believe you would have already copied the access token and then the next step is to figure out which API will be hitting first or which request will be triggering first. Let's go to the 'Workspaces' and see what are the methods that are supported for a workspace. A workspace is the highest level organizational unit in Asana now. Because we have signed up by our personal email. So if you have signed up with a personal email like Gmail or other public emails, then the Asana doesn't allow you to convert that particular workspace to an organization.

You can convert workspace to an organization only if you have a domain or a business domain, for example like RCVAcademy.com or if I have an email like manage@RCVAcademy.com, I can sign up with that RCVAcademy.com and convert it to an organization. So, no need to worry about that. We'll work out the other way to work with the API and learn the API testing even though you are not able to convert to an organization and work with some of the APIs that are listed here.

So, if you see this Workspace here, so we have the GET /workspaces API and GET /workspaces is basically a very simple request which is the GET method and then there is an endpoint which is app.asana.com. And then, there is a resource, anything starting from the forward-slash after .com is the resource. So, /api/1.0/workspaces is the resource. And then anything after the resource, which starts with a question mark is the parameters.

Okay, so we'll copy this whole location and then go to Katalon Studio and here in the object repository, I have already created a folder Asana where I am keeping all the requests that I am triggering. So, I will just say right-click on the folder, click on New and click on new Web Service Request and I'll paste the URL that I have copied. And I'll say 'Get all workspaces.' Okay and this request will provide me all the workspaces.

So now, I have created this particular GET request, I can change the method to anything I want to but because this is a GET request, I'll just keep it as GET and then let's see if it needs the parameters. So, it needs certain parameters if you want like 'pretty' output or optional fields or limit but these are not the mandatory ones. Okay, so we can ignore these as of now because they are not mandatory and then let's try to hit this request without the authorization and let's see what happens.

So, I haven't done any authorization here. You can see no authorization and if we hit this particular request, it will ask, ''do you want to save the changes?'' We'll say OK and there is some problem. There is an illegal character. Let's see where the problem is. Go to the details and let me close this and go to the body. Looks good. OK, so here you can see that there is a space after the 'workspaces' and this is what the issue is.

So we'll just remove this space, OK, save it again, and hit the request. Now, these are very small things but very important when you are getting these errors and then trying to diagnose. So, this will help you to learn a lot more rather than just following a happy path. So if you are encountering the issues and you are resolving it on your own, you will be learning a lot more.

So now you can see here in the 'Response,' there is a JSON response and JSON has been selected automatically by Katalon Studio. It's 'pretty' formatted and it says ''Not Authorized'' and the reason for this is because Katalon API requires the personal access token OAuth 2 to be configured for the request that we are going to hit. So, to configure that or token, what we'll do is we'll go to this authorization tab here. And here in the drop-down, select 'OAuth 2.0' and in the 'OAuth 2,' you'll see at the bottom, if you scroll down, you will see the 'Access Token' field here.

OK, and what you need to do is just copy and paste your access token. Okay, just I haven't copied that. Let me copy it. So I'll paste the copied access token and once you have provided your access token, then click on 'Update to HTTP Header.' OK and now you'll see, in 'HTTP Header,' you will see the authorization with the value that has been updated. Please note that this access token is sort of your password. So do not disclose this access token. This is for your personal use and you should use it for your own and do not disclose it to any other person.

And once this access token has been configured, if I request or save this particular request, so I'll save it and then hit the request again, it will provide me the response of whatever workspaces are present in this particular instance. So you can see that I have got the ''gid'' for the ''workspace'', ''IT'' and that is available as the response. So there is one workspace which we have created and that has been displayed. So this is basically how you will configure your authorization with OAuth 2 for Asana API in Katalon Studio.

Now, in the next tutorial, we will understand all four operations like POST, PUT, DELETE. So we have already seen GET request, you will see POST, PUT and DELETE. And then we'll go further with the automation of the API using Katalon Studio. So hope you like the tutorial. Thank you very much for watching.

Hello and welcome to Katalon API testing tutorial. In this tutorial, we are going to learn how to trigger the first POST request in Katalon Studio for the REST API testing. So, before we get into the direct triggering the POST request, I'll go through the home section of the Asana App that we have signed up and explain the things that we can do through the UI testing and why API testing helps a lot, and why you should be thinking about shift left testing when doing the actual like designing your test cases, and making sure how many test cases should be the API test cases rather than the UI test cases or the web UI test cases.

Now, here I am on the home page of Asana API and then I have a project that I have created. Now, in this project, if I go to this project, I can add tasks through the UI right now. For example, you are working on testing this Asana application and you had to test all these functionalities like creating the project, creating tasks, deleting tasks, editing tasks. Unless this UI was available to you, how would you test it?

And that's the whole purpose of the API, that in case your APIs are available or even if there is a partial API that is available that you can still mock some of the functionalities and test it. And you don't need to wait for the UI to be there. So for example, in this case, I want to test 'Add Task' and that's the POST request that we'll be using or explaining in this tutorial.

So when we go add tasks and we'll say 'This is a sample task added from GUI.' OK, so now this sample task has been added through graphical user interface but now how we are going to add this similar task from API? Okay, how will I use the Katalon Studio and try to test the addition of the task through the API? Now, in order to add this task through the API or Katalon Studio, we need to use the method POST. So anything we want to add to the database or add an entry, we need a method POST and for retrieving any information, we use GET.

So, we have seen GET method already. Now, let's see how we are going to create a task using the POST method. Now before we get into any of the details of the API, we need to read the documentation and that's what will happen in your projects as well. So, we'll go through the documentation of the provided API. So for example, here I am at the developers.asana.com, which explains all the API features.

So we'll go to Tasks and see what all methods are being supported in Tasks. So, we can see that we can GET the tasks or we can retrieve the tasks in the project. And in the workspaces, so there are many parameters that you can utilize but here we are interested more into the POST request so we will go to the POST. And POST is used to create a new task and for, you know, just the task endpoint and then there are some parameters which is the body parameter, which is the JSON data here that we need to pass.

So, this looks pretty big data, so you can provide a lot of information in the Body parameter. And if you go through this data detail here in the drop-down, it will explain to you what all parameters you can pass when you are creating the tasks. But to start with, we don't need to worry about all the details in this particular task. So don't get panicked with the number of lines in the Body parameter. We will strip it down to just very minimal parameters in the body.

Now, what is the endpoint? So, endpoint, the same, app.asana.com, and then the resource is /api/1.0/tasks. Okay, so let's copy this whole URL and go to Katalon Studio and then in Asana folder, what I'll do is I'll click on New, click on Web Service Request, and then we'll paste the URL. OK, and this request is basically what I'll name it, I'll say 'Create new task using POST method,' OK. So, just hit OK and now I'll open this method.

And this method will be the POST method. OK, so change it to POST and in the query parameters. So this is basically task. If we go to the documentation again, you have the Body parameter. Okay, so we have to get this JSON body parameter. So I'll copy the whole thing and then we'll strip it down further. So we'll go to 'HTTP Body' in Katalon and here you can simply leave it to 'Text' and change it to 'JSON' formatting and paste the body here.

So now what we are all interested in, we don't want to add all the fields here. So we'll remove all these followers. We'll just put the ''name'' there. So I'll remove all that data ''followers'' and ''HTML notes.'' We will just keep ''notes'' and we'll remove the ''parent'' and then we'll just keep the ''project'' because we have to provide either the project or the workspace. So, that is mandatory. So if we go to the documentation here, we'll get to know that we have to provide the project or the workspace. So here, so workspace is GID of an object, and then the projects - array of object GIDs.

Okay, it can be either of these. So, it will identify where this particular task needs to be created. So, now I have the name, I have notes, so I have removed all the information that was there which we don't need. So, I'll just say change the name to 'this is sample task created by Katalon API testing.' Okay, I'll just put the name there and then I'll copy the same thing 'This is sample task' and put it in the notes and then we have to provide the project GID.

OK, so project GID. I'll just trigger this request. So, once we run this request, we'll get the project GID. Okay, so, project GID, copied. And now you'll see here that once you save your authorization, once you say 'Update to HTTP Header', your auth details get saved in the 'HTTP header.' So every time, you know, like you'll see no auth here, that doesn't mean that HTTP header hasn't been set so that's why even though the type is not here, because the HTTP header has been set already when we said update to HTTP header, the auth details are already there in this particular request.

So, let's copy this particular project GID. Go back to this POST method and in ''projects,'' we'll paste this GID. Okay, now let's see what are the details in this particular JSON that we are providing. So we are providing the name, notes, and the project GID. OK, so let me remove this comma here and now this is formatted JSON. And now we can run this particular request. But before that, we need to see that we had already set the authorization. We haven't set any authorization there. so I'll quickly go ahead and set the authorization.

So we will say 'Oauth 2.0' and then in the password credentials, I'll paste the access token and click on 'Update to HTTP header' before we can send this request. So, let me quickly do it. OK, so I have updated the authorization details and now we will save this request and run this. And let's see what happens. Let me save the changes. So, ''cannot send the test request,'' there is a legal character in path at index 35. Let's see what the issue is.

So, it looks like there is a space. Okay, so I'll remove the space there and that's the common issue that you'll find if you're copying and pasting, configuring, forgetting, you know, like the spaces. So I've removed this space. Let me save it again. And if you go to the HTTP body, I have just mentioned the project ID where we are going to create this task, just the name, and the notes, so to simplify the whole JSON request or the body that we are going to send to just couples of lines, which is easy to understand and to follow if you are going to learn the API testing.

So, let me run this again, POST request and see what happens. So now, you can see the response, the status code '201 Created,' what was the elapsed time, how much time it took and what was the size of the response. The response body is 'pretty' formatted and it's in the JSON format and it provided us with all the details of this particular task that has been created, where the memberships are, who is the follower, etc.

So all the details have been provided. Now, if you go to the UI. Okay, let's go and verify on the home page that this particular task has been created. So this was the task. 'This is a sample task added from GUI' was the task that we created through the graphical user interface. And you can see, 'This is the sample task created by Katalon Studio API testing,' and that is what we have created using our Katalon Studio API test.

And you can see in the description, 'this is sample task.' So we had used two fields. Here, so, 'this is sample task' in the ''notes'' and in the ''name'' we had used, 'this a sample task created by Katalon Studio API testing,' which are updated as the name and then in the description. And the project is basically the project ID. If you can see, this is created in the RCVTestProject, which is this particular ID. So, if you see, 532, ending in 532 is what the project ID is. Alright, so that is the POST request to create your task in a project in Asana using Asana API.

So, hope you like the tutorial. In next tutorial, I'll cover the PUT request to update the same task and then we'll use the DELETE request to delete the same task. And after that, we'll start with our end-to-end testing and some of the parameterizations in Katalon Studio API testing. So hope you like the tutorial. Thank you very much for watching.

Hello and welcome to Katalon API testing tutorial. So in last tutorial, we have seen how to send a POST request and create a task in Asana. And in this tutorial, we are going to learn how you can send the PUT request and update the same task using the using the Katalon Studio.

So now, on my screen, you can see that the GID we are seeing here is the task GID for the task that we have created. So we'll simply copy it and then we'll go to the documentation. OK, so let's see how we can update the task. So, in the Tasks documentation in the http://developers.asana.com/docs, if you type 'Tasks' and go to 'Tasks,' we have seen that how to post a task. And now once we have posted a task or created a task, the next is to update the task which is the PUT request.

So, we'll click on the PUT request and you'll see the 'Update a task.' We will utilize the PUT request to update a task. And here if you see there are certain parameters that we need to utilize. So we need the body parameter and then we need the task GID as well. So task GID is required for whichever task you are going to update. We need the GID for that particular task. So we'll copy the location or the URL and go to the Katalon Studio and here we'll create a new Web Service Request, provide the copied URL and we'll say 'Update a task,' then click OK.

And now in the 'Update a task' tab, the first thing we need to do is to change it to a PUT method and then provide the task GID. Where is the task GID? Task GID is from the response that we created the task. So we created the task and this is the task GID, so copy it. And in the 'task_GID' section here, we'll paste it. So, we are doing it manually at the moment. We won't be doing it manually in future. We'll be doing a lot of parameterization and automation. Just keep following the series to learn all those parameterization and data externalization concepts.

So, I have pasted the task GID as of now. And the next thing is to update the body parameter. So, task GID was required and then the body parameter is what is required. So, we'll copy the body parameter. Go to the HTTP body, go to the section here, paste the body parameter. Okay, so we won't be updating each and everything in this particular JSON. So, we'll remove most of this stuff here.

We'll just leave the name. Okay and that's pretty much what we are interested in. So we'll just understand how you can trigger the PUT request and we removed everything else in the data dictionary or the object. We just keep the name and we'll say 'Update task name from Katalon Studio API Test.' Okay, so we know that this is the name that we are going to update for this particular task.

Now, we haven't done the authorization for this particular request. So we need to set up the authorization as well. So, we'll go to the 'OAuth 2' and I will paste the token. So let me paste it quickly. So I have pasted the token. I'll click on 'Update to HTTP header.' We'll go to the body, we'll cross check it once again. That comma is not required here and now let's change it to JSON. Okay so that's Jason formatted and let's save this request and run this PUT request.

So if we run this request now, let's see what's the response. Sending the request and here you can see that the response status is '200 OK,' what is the elapsed time and the size of the response. Now, you can see that this particular task with GID that we have copied here has been successfully updated with the name of 'Updated task name from Katalon Studio API Test.' So, this should be available on the UI now.

If we go to the Chrome and the home page, you can see that 'Updated task name from Katalon Studio API Test' has been updated and the description is still the same because we haven't changed the ''notes'' in the API. Now, if we want to change the notes as well, the only thing you have to do is you simply change or add the ''notes'' parameter here. Put a comma here. And we'll say 'Updated notes.' Okay, all right, let's rerun it. Save the request and rerun it and see that notes are getting updated as well.

So, notes have been updated. Go to the UI and you can see updated notes. So similarly, if you want to change the assignee, due date, everything is possible through the API. So, you can see here in the body what are all data objects that you can use, for example, GID, or source type, name, created, assignee, assignee status, so N number of things that you want to use in your API PUT request.

You can add these and form your body parameter to send the PUT request in the Asana for the Asana task API. So don't just keep practicing through the name and notes. Try to work on this JSON body. Try to add the due date or due on then completed flag, etc. And try to experience or explore it a bit and understand a lot more with the combination of the body parameters, how you will form the JSON.

This will give you a lot more visibility and flexibility in understanding how you are forming your JSON requests and sending the POST or PUT requests in Katalon API or Katalon Studio API testing. So hope you like the tutorial. Please do share and subscribe. And thank you for watching.

Hello and welcome to Katalon Studio API testing tutorial. In this tutorial, we'll continue our CRUD operations and we'll understand the last basic operation in CRUD which is the DELETE operation. So we have seen the GET request, we have seen the PUT, POST, and now we are going to understand how we can delete the task that we had created in the POST tutorial.

So, we had utilized the POST method to create a task in Asana and now we will use the DELETE method to delete that particular task. So we'll go to the documentation and understand in the Tasks that we have the DELETE method available there. Now, in this DELETE method, if you see that an existing task can be deleted by making a DELETE request. And the in UI, and what you have to do is you just have to provide the task GID.

So, you have the endpoint which is app.asana.com. And then in the resource, you just have to append the task GID to that particular resource which you want to delete. And then in the Response, it will send the blank data dictionary with nothing in that particular dictionary. So, let's copy this DELETE request and go to Katalon Studio and in the Asana folder, I'll right-click, go to New, click on Web Service Request and provide the URL there. I'll update the name to 'Delete tasks from Asana project.'

So, we are deleting the tasks that we created. So we'll just click OK. And now in this particular request, in place of task_gid, we just have to provide the task. So we'll use the same task GID that we created and go to the DELETE request. In the resource itself, we'll just copy and paste this particular task. Delete it and paste the GID. And that's the only thing we have to do apart from the authorization. We'll set up the authorization as well. So let me quickly set up the auth and then we'll trigger this particular request.

Okay, so I have configured the OAuth 2 or the authorization for this particular request. Let me save this request and click on Run. And now this particular task should get deleted. Okay, so it says, '200 OK' but that's not what we were expecting. In the response, it should give us a blank data dictionary. So, the problem here is that we didn't change the method to DELETE. If you want to delete any resource or any data, then we need to select the method as DELETE.

So we didn't change it to DELETE, and what it did is it triggered the GET request and it caught the details of this particular task and displayed all the details here. So, we'll change it to DELETE, save it again, and now you can see DELETE request has been updated here. And we'll run this particular request again. And now we should be getting whatever expected response that we think.

So, you can see that now there is a blank data dictionary that has been written. The object contains nothing and that means this particular task has been deleted. If we go to the RCVTestProject here, now you can see that there is only one task that is present there. And that the other task that we created has been deleted. If we go to the details of this particular task, you can see, this is the task GID. Let me copy that and try to delete this one as well.

So we'll paste the GID that we just copied. Save this request and rerun this request. And now the other task that is there in this project, which we created manually, should be deleted as well. So you can see the task is deleted. And this is a sample task deleted from GUI. So when we trigger the DELETE request, this has been deleted and it's currently in the bin which you can undelete or delete permanently on the UI. That's the functionality that has been provided. But whatever DELETE method is supposed to do as part of this request DELETE that has been done through Katalon Studio API Testing.

So, this concludes the basic CRUD operations that you can do through the Katalon Studio and these are the operations that you will be using most frequently when you are doing the API testing. There are lot more operations, for example PATCH which is similar to PUT. There is a very major difference between PUT and PATCH but both are utilized to update the data into the database or the resource details. Then there are a lot more which we'll be discussing in the future tutorial.

But these four GET, POST, PUT, and DELETE are the very basic CRUD operations that we have already discussed and trigger these requests and how you will be triggering these requests manually to do the API testing manually. Now in future tutorial, we'll start doing a bit of parameterization and then we'll start working on the automating this whole end-to-end flow using Katalon Studio. So hope you like the tutorial. Thank you for watching.

Hello and welcome to Katalon API testing tutorial. In this tutorial, I'm going to talk about the types of variables supported by Katalon Studio and I'll also touch base on the profiles in Katalon Studio. So I'm on the Katalon Docs page at the moment. If you see, and the types of variables that are supported in Katalan Studio are three types. The first one is the Groovy Variable that is supported in the Groovy scripting if you are doing the script. Then, the second one is Test Case Variable. And, the third one is the Global Variable which is part of the Execution Profiles and that's why I'll be covering the profiles in Katalon Studio as well.

So, as part of this tutorial, we will cover Test Case Variable and the Global Variable and the profiles. And Groovy variables, we will cover once I start with the scripting because we haven't started with the automated scripts yet. So it's best to understand test case variable and global variable first before we go ahead and understand the Groovy variable. We will cover Groovy variable once we start with the scripting.

So, the first variable that we'll be covering is the Test Case variable. So let's go to the Katalon Studio and we'll open some of the requests here. So, I'll open 'Create a task' and then I'll say 'Get task details.' So if you see, these two requests here, the first request is the 'Get task details' which is the GET method and we have hard-coded this value here which is the task GID right. Now that not a good practice if you are going to automate or do the testing of the API or any sort of testing, hard-coding any values in the test itself is not a good practice.

Because, say for example, you have hard-coded this value in 15 different test cases and tomorrow this value gets changed or you are you want to to do a parameterization or you want to test the same test cases with different task IDs, then you have to go through all those 15 test cases and update this, which is really tedious job. That is why we need to understand the profiles and the variables in detail so that we can utilize these and have a good maintainability of our test cases.

So what we can do here is we can define this value or we can define a variable in the test case itself, or we can define it at the global level in the Profiles. So how we can define it in the test case level is simply if you open this particular request, in this here, the headers, we will see 'Authorization' and 'Verification.' In the 'Variable' section, you can click on 'Add' to add a variable. And it will automatically number. So you can provide the name. So, I'll say 'task_gid' and then here you can define the type whether it's string, number, Boolean, whether it's a global variable. So, all these things you can define.

So what we'll do is we'll just leave it as string and then we can provide the value here. Okay, so we can provide the value as the GID value. And that will be passed on. So, we'll change it to number because this is the task GID and we'll change the value. Now, this number, how do we access this number from the variable?

So, the command is pretty similar or the format is very simple. You just say ${task_gid}. So, now this line here, the highlighted one, will be able to access this variable, the value in this task_gid variable, and append that value in this, after the 'tasks' here in the resource. And once you will hit this request, it will send you the response.

So, let me save all these details so here. If you see the small star, that means the request hasn't been saved. So let's save this particular quest and now you'll see the star has gone. That means this request has been saved. Let's run it and it should give us the task details that we have provided. So, you can see this is the task ID that we provided and we have got the details of this task from this particular response. Now, that's how you will set up the local or the test case variable.

Now, what about the Global Variable? So, when it comes to global variable, there is an option to define the global variable in the Profile. Now, here, if you see, there is a default profile. So, Profile in Katalon Studio has been provided to enable us to maintain or manage multiple test environments or execution in multiple environments through the user profiles. So what we can do is we can define multiple profiles.

For example, you have 3 environments, one test environment, one pre-prod environment and a production environment. You can define a profile for each of these environments, And in these profiles, you can set up your global variables and access accordingly. Now here, there is a default profile and here, in the right-hand side at the target, if you can see, this is the profile drop-down which will list the profile. Because there is just one profile with that has been selected and when we are defining our variables, we are basically defining the variable at the default level.

So, let's first understand the the defining of global variable in the default profile. So, to define it, just open the profile. And in the profile, you will see an option to add. Okay, so we'll add the name. We will say just 'task_gid' and then we'll change the type to number and then we'd provide the value. Okay and that's pretty much it. That's how you define the variables at the global level.

Okay, let's save this profile, and then we'll try to access the value that is in this task GID from the global level. Before that, we will also define one more variable, say for example project GID. And we'll use this project GID in this particular JSON request or payload and we won't hard code this value here. So, we'll take this value from the default profile or a default profile global variable. I'll open this variable and I'll add another variable. We'll say 'project_gid,' change it to the type number and we'll provide the value.

So now, we have two variables differently. One is the task_gid and another one is the project_gid. Now, before we go to the 'Create a task,' in the 'Get task details,' let's try to access the task GID not from the local variable, or the test case variable, but from the global variable. To do that, the only thing you have to change is basically just to add 'GlobalVariable.task_gid' and this is case sensitive so 'G' will be capitalized, 'V' is capitalized. So, ${GlobalVariable.task_gid}.

And now once you save all these requests here, then the value that will be picked, the task GID value that will be picked, will be picked from the global variable which is in the default profile and not from this local variable. So, let's try to run this. Before running, because these both values are the same, you won't be able to figure out which value is being picked up. So let me change the value that I have defined at a global level, the task GID value here, and I'll make it some invalid value.

Okay, so that it is very clear that the global variable is being picked up. Okay, so we have saved all the requests. Let's run this and see the response. Now you can see, ''tasks: Not a recognized ID'' because this is the ID that we have defined at the global variable level in the default profile, and that is not a valid ID, which clarifies that this task GID that we have defined here as GlobalVariable.task_gid is being picked up from the global variable in the default profile and not the test case variable.

Okay, so, syntax is very similar, we just have to say, $, curly braces, GlobalVariable, dot, task_gid, or the name of the variable in the global context, and close the curly braces, to access the global variable. To access the test case variable, we say, $, curly braces, task_gid or the name of the variable. So, that's how you will access the local and global variable in your resource. Now, coming back to 'Create a task.'

Okay, so in 'Create a task,' we had provided or hard-coded the project GID in the JSON. Now, if want to remove this hard coding from this JSON request, the format or syntax will be exactly similar, so ${GlobalVariable.project_gid} or the name of the variable that you are going to define in the default profile. So now, this project GID will be picked up from the default profile's project_gid. This value will be picked up in this particular test case.

Let's save all these requests and if you run this now, you will get the same response that the task has been created successfully and this is the task ID that has been created. So, status is '201 Created' and it has been successful. Let's change the value in the default profile and I'll put some junk value there so that you can easily correlate that the value that is being picked up from the project GID is actually from this default profile.

Let's run it again and now the request should fail. So, you can see this value is not a recognized ID. So that's about the test case and global variables in Katalon Studio, how you can define it and then how you can access it into your JSON request or into your resource. And the other thing that we covered is around the profiles. So, we'll cover a bit more on the profiles and how you can use profiles to define different test environments and work on the profiles in the next tutorial. So, hope you like the video. Thank you very much for watching.

Hello and welcome to Katalon API testing tutorial. In this tutorial, I'm going to talk a bit more about profiles in Katalon Studio or execution profiles. So, in the left-hand side, in this Test Explorer navigation, if you see, we have the profile section and 'Default' is the profile that is always there when you install Katalon Studio. Whichever test case you are executing by default, if you define any global variable, you define it in the default execution profile.

To create a new profile, now, when we talk about profiles or execution profiles, these profiles are basically to segregate your test environments. For example, you have different test environments which have different endpoints, a test environment, UAT environment, and then you have pre-production environment and production environment. All those will be having a different set of configurations or different default parameters, which you might be defining in your profiles or execution profiles or different endpoints which you will try to hit.

That is the whole purpose of giving the flexibility of profiles so that you can define your test environments and define the global variables in those profiles which are specific to those profiles or to those execution environments. For example, test environment might have something specific, very specific parameter or variable which is specific to test environment, or production might have something specific, in endpoints or the URL is the first thing that will be very unique for each environment.

So, to define a new profile, you just right-click and click on 'Execution Profile' and provide the name of the profile. So, I will just say 'TestEnv' (for test environment) and hit OK. Now, you'll see another environment profile, 'TestEnv' profile, has been created. I'll create one more and I'll say 'PreProd.' And then I'll create one more for the production. So this is usually how it will be in the actual testing scenarios, right?

So, you will be having a set of test cases that you want to execute on different test environments before you actually release your tests or release your code into the production environment. Now, when we create these profiles, for example, let's open the 'TestEnv,' what you can do is we can add the variables, for example, URL or the test environment URL or pre-production URL. It will be sort of different for each of these execution environments. For example, test environment might be something, we'll say, 'app.asana.com' or it might be something like 'testapp.asana.com.'

So, then let me remove this 'asana' from here and just say 'testapp.testrcv.com.' So just a dummy URL, just to show you how we'll be able to create these URLs and use these different URLs in the executions. So, we will say OK. Now, in the 'PreProd,' we will add another same name URL, as a string, and then 'https' and provide the endpoint URL and name it as, let's say, 'uatapp.testrcv.com,' click OK.

Now what I have done is I have defined the URL in the test environment as 'testapp.asana.com' and then in the UAT, it is 'uatapp.testrcv.com.' So, both the environments will have different URLs. Now, when we want to execute any test case, for example, 'Get task details,' so here as of now, you can see that we have hard-coded this value in each of the test cases, right. So this URL or the environment URL is hard-coded in each of the test cases.

Now, say for example, tomorrow you want to execute these test cases in different environments, you won't be able to. I mean it will be a very tedious task to go and update 100, 200, 500 test cases that you have written with these endpoints. So, that is the whole purpose of having the execution profiles so that you don't hard-code this value here. And what we can do is similar to when we learn about the global variable or the test case variable. We will simply say, ${GlobalVariable.url}.

So now, what will happen is depending on which profile you select from this drop-down, it will pick the URL from that particular profile. So, we have defined URL variables in the test environment and in the pre-prod. If we choose the test environment now, it will pick the URL from the test environment. And this test case will run successfully or this request will run successfully. We haven't added these requests to the test cases yet. So, we will say this request will run successfully. So let's save everything and run this request.

Because this is a dummy URL, it will throw an error but that's fine, I just want to show you that it's picking the URL right. So, you will see that 'testapp,' it gave us a warning and it said, ''testapp.testrcv.com: nodename nor servname provided, or not known.'' OK, but you can see this URL has been picked up from the test environment. Let me hit OK and let's change it to pre-prod. And then run it and now you will see, 'uatapp.testrcv.com,' that another URL has picked up which has been defined in the pre-prod environment.

Okay so let me change it to 'UAT' which has been defined as 'PreProd', so now 'UATProd.' Okay, so we have defined two URLs, one for the UAT environment and one for the test environment. Similarly, if you have multiple test environments and you want to execute same test cases in all those test environments, what you need to do is, in all these requests, you just don't hard-code the value or the endpoint in the test case, you just replace it with the global variable with a dollar sign, curly brace, and the 'GlobalVariable' dot whatever the variable name that you provide it, like in this request 'Get task details,' we have provided GlobalVariable dot URL.

So now, this value is not hard-coded and depending on the profile that we'll choose, we can execute a number of test cases accordingly without changing any of the endpoints. So that's one usage of the profiles or the execution profiles and it is very helpful in Katalon Studio if you define your test cases accordingly and define your profiles in a better way. So, the maintainability of your test cases will be really easy.

Now, the next thing will be around. For example, in the test environment profile, I have defined another variable, say, 'task_gid,' which I'll change to the number and I provide value there. So, just enter value there, ending with 456. Save this request. And now, in the request, 'Get task details,' I have provided ${GlobalVariable.task_gid}. And in the test environment, I provided the task_gid. Now, when I run this particular request on the test environment, on this execution profile, let's see which task GID it will pick.

Because in this particular 'Get task details,' there is a task_gid defined at the test case level then there is a task_gid defined at the global variable level. For global variable, there is one in the test environment and then there is a default profile which also has the task GID. Now, when you run this particular task, 'Get task details,' and you have defined to pick it from the global variable, the first thing that this test case will do is it will check which profile is selected, which execution profile is selected. It will see the test environment is selected and will check whether this task GID is defined in the test environment.

If it is defined, it will pick the value from there. Otherwise, it will go back to the default profile and check the task GID in the default profile. And if it is there, it will pick the value from there. So, let's execute and see that this is happening because I will run this. Let me change this URL first. So, in the test environment, I'll put the correct URL. I will say, 'app.asana.com' so that the request gets through successfully. So, click OK, and let me save all these requests, I'll run it again in the test environment.

And now, the task GID that has been picked up, you will see 34543456 which is defined in the test environment. Now, if there is no task GID defined at the test environment profile level, let me delete it and try to execute this request again and then see. Now, you will see 115536095, which is the task GID defined at the default profile level. This is the hierarchy basically.

So, if there is a variable defined at the test case level and you want to use it, you don't need this global variable here. It will pick from the test case level. If you have defined a variable at the profile level, it will pick up from that particular profile if there is any variable defined in that particular global profile or execution profile. If not, it will go back to the default profile and try to get the details of that particular variable. If it is defined, then it will pick the value. Otherwise, it will throw you an error.

So, that's a brief about the execution profile in Katalon Studio, very helpful, very easy to understand. And this is very important when you are doing your actual project testing and defining your test cases. Defining your test environment separately and not hard coding the endpoint in your test cases is the key for good maintainability of test cases in any of the API testing. So, hope you like the tutorial. Thank you very much for watching.

Congratulations! You've completed the Katalon Studio API testing course. Just to recap, through this course, you've been shown a way to initiate GET, also SOAP requests for REST API and SOAP web service respectively. Then by gaining access to Asana API, you can use Katalon Studio to conduct test automation in real time.

Moving on, after triggering POST requests, PUT requests, and testing your PUT request response, finally, you'll be able to examine Katalon Studio's available variables to get a better grasp on execution profiles. This step is important to manage test executions in various test environments.

Now that you were informed with the basic API testing concepts, we hope you can apply what you've learned here to easily design and automate your API test cases with Katalon Studio. Join other courses to learn more about automation testing topics. We look forward to seeing you there.