API Testing with Postman Workshop

Hello and welcome to this session about API testing with Postman. My name is Pooja Mistry. I'm a developer advocate and I'm excited to be sharing this workshop content with you. Today's session I'll be walking through a lot of different aspects of testing with Postman and hope to share some things that you might not be aware of.

So we'll be going through a workspace and collection and giving you a overall overview of Postman and some things you can do while testing when it comes to Postman. So just introducing myself. I've worked in the DevRel, DevAdvocacy space for about three years now and I'm excited to be educating others and sharing information specifically regarding to Postman.

So in today's agenda we'll be going through is we'll talk about Postman's UI and we'll kind of understand the terminology for those of you who are new to the platform. And we'll talk about how to get started with testing with Postman and learn some advanced testing techniques. And I'll be demoing some interesting features for you to kind of take a look at that you can get started on your testing journey. And then I'll be sharing a lot of additional Postman resources.

So essentially for those of you who are not familiar with Postman, Postman is a versatile platform for API testing and it's over used by over 25 million people worldwide. So if you're learn interested in learning a little bit more about Postman and its statistics, we have the Postman state of the API report which you can Google and you can get a lot more information on statistics around APIs and API development. So with Postman, Postman simplifies each step of the API life cycle and it streamlines collaboration so you can work and create APIs faster. It's an interface for both the producer and the consumer life cycle and it allows, you know, users to not only discover, evaluate, test, deploy, and observe, but they are also able to define and develop their APIs and secure them and distribute them accordingly. So it is trying to be this all-in-one life cycle and we'll walk through the entire UI and kind of how to get started with it. So essentially we are going to kind of get into things like working with variables, understand how testing works, learning some sort of advanced testing and automation techniques, building additional, and then I'll be sharing some additional Postman resources.

So to get started, feel free to take a look at this link where we'll be going through this workshop. So this is for I guess the TestJS summit that we were at previously, that is part of GitNation and we should be able to kind of go through Postman in that way. So I'm going to go ahead and get started and kind of show you what the Postman UI and the workspace looks like. So in this case, we are in this workspace and we have a public workspace. So within Postman, you can create different workspaces. Workspaces allow you to work and they're a template for you to get started. You can look at some of the templates that we have available. For example, you can always create a blank workspace, but if you're interested in some of our templates that we have available, if you're an API producer or an API tester, you may be interested in some of these templates. Like for example, this is a specific template associated to API testing. I'm going to go ahead and take a look and kind of show you this workspace, which is a public workspace. So this workspace, if I share the link with you all, you should have access to some of the collections that are available in this workspace to get started with. And the idea here is that you would like to go ahead and fork a collection to get started with in this specific workspace. So for example, since this is a public workspace, I might be interested in creating a, let's say I create a API testing workspace and call it API testing.

I can create that workspace, which it gives me access to my specific team members, whether that's my team or if it's personal or partner or public in that case. So I'll go ahead and create that workspace just so you know what it looks like to create a workspace with a template. And in a template workspace, we have some pre-created collections. Like for example, we have a collection for contract testing, integration testing. We have a collection to help you get started for writing basic tests, mocking data, performance testing, and then even regression testing. So we'll walk through some of these testing examples in this workspace, but for the most part, I'm going to go ahead and go back to my home page where my workspace exists. And I'll take a look at the workshop that we've created. And I'll go ahead and fork my first folder, which is an introduction to testers into my API workspace to get started with that workspace. So let me go ahead and create that fork and you can see that I'm able to then figure out which workspace I'd like to go ahead and fork that to. And I can always watch the original collection in the original workspace to get some more ideas on how to kind of to see if there's any changes. So for those of you who collaborate with your teams, this is very important because it allows one subject of truth, which is your main workspace that you work with. And then for just like how GitHub is created, you want to create a fork of that repository or a fork of that collection. And then if you want to submit any changes, you can always submit pull requests into a workspace similarly. So this is what allows for higher level of collaboration. So I'm going to go ahead and fork that collection and it should be able to you should see that I can once I create the fork in my API testing, it should be able to, you could see that that fork was created. So in this case, the reason why we wanted fork is to work in our own environment in case we want to do any experiments and testing. Since I own the original workspace, I will be able to send scripts and things like that through that. But since it's a public workspace, you would like need to fork to even send your requests.

So to get started, I wanted to kind of show you a couple of very intro testing aspects. So when it comes to testing and Postman, we have collections, and we can always create new collections. And another place where we can take a look at how to create collections is by taking a look at some of the templates that we have available.

So for example, we also have templates available for anybody that is based on roles, based on API use cases based on industries. So for example, if you were interested in artificial intelligence and wanted to take a look at some of the APIs available, we have entire collections that help you get started easier and if you don't want to start from scratch. But in our case, I wanted to show you some examples of what our collection looks like.

And then the first thing that I wanted to share about a folder in our collection is all about getting started with variables. So variables are a very important aspect of Postman and they allow for a lot more reuse and store of values. So by storing values as a variable, you can reference it throughout your collection, your environment variable, your requests, your test scripts, and variables help you work efficiently and collaborate with teammates a lot more dynamically. And you're able to set up a little bit more dynamic use cases when it comes to working with variables.

So in this case, I wanted to share that Postman has the ability of global variables, which are variables that you can use throughout your workspace, collection variables, which are specific to your entire collection. So in this case, I have variables that are specific to this collection and these folders and these requests. I can create environment variables. So global variables are that scope through the workspace. Environment variables are variables that I can export out and I can share. So, for example, if I wanted to call this like the new test environment and I wanted to use a base URL here. And let's say I have a production environment that has a different base URL. I can create multiple environment variables if I wanted to. So, for example, like I could add another environment variable here and I can call this one new production environment and have another variable value, for example, base URL here. And I can either set that as a default or a secret, which will encrypt my values here. So, for example, if I had specific API keys or API tokens, I can work with different variables as associated. And so based on the environment that I'm interested in, I can kind of work on either a production or test environment. So you can see that these environment variables are very useful when it comes to testing. So that's kind of what it looks like to kind of get scoped. So if we were to take a look at our request in itself. So here we have a ECHO URL, which is using our URL for the Postman ECHO service. And it is scoped to the collection variable. So you can see that that base URL for that ECHO URL is scoped to the collection level. And they're available throughout the requests and they're independent of environment variables. So basically, collection variables don't change based on the selected environment.

So I'm going to go ahead and take a look at this ECHO example and kind of show you a little bit about what it looks like to kind of work with a request. So with ECHO, you can use this as a testing API because what it does is it always just sends back some data that you've sent it. So here I've added two query parameters, one of the first value and of a random color. So here you can see that I have a variable set for value one. And then I have a dynamic variable here set, which is part of Postman's inbuilt library. And this is globally across every workspace. And you can see that this is a random variable that you can kind of take a look at in terms of like it's it allows you to put in any random values.

So I wanted to share with you the kind of the Postman learning center. And so let me just kind of just make sure that I am so much interactive. Okay. So if we were to go to the Postman learning center, this is where all of our documentation exists. And so we have documentation on all of our our features. So if I were to take a look at dynamic variables. I can take a look at some examples here where I can use variables that are globally inbuilt into Postman, such as timestamps, random colors, text integers, random passwords, random, you know, two letter languages. So this is very useful when it comes to testing and doing any mock testing. And for a lot of people that do testing in other ways, they try to import these libraries. But this is a really interesting feature within Postman that is available directly as a variable.

So to get started working with some of these random features, all you have to do is make sure that you have that dollar sign. And then you can take a look at any of these random variables to create dynamic use cases. So in our request itself, we have two sets of scripts. So we have a pre request script and a test script. So within the pre request script, we can use this thing called pm dot collection variables dot set. So here we have a set of snippets that are available. So for example, we can use snippets such as, you know, clearing variables getting and setting collection variables, sending a request. So these are all snippets that allow you to work specifically with variables, for example, if you wanted to get a specific variable, or set a specific variable. So if I were to set this variable as blue and save this request, you can see that when I for that first value, um, I am going to go ahead and once I send that request, you can see that has changed because my current value has changed. So when it comes to working with variables, especially on the collection level side, there's initial values and current values. And so the difference between both initial and current value is basically, which values will get saved when you share, share the the collection with others. So, for example, ideally, you'd want to keep your initial values, if you were going to go ahead and export and share that collection with others for security reasons, and you don't want to share like your API keys, etc. So whatever is set in your current value is what is being set when you locally work with that particular collection at that time. So that is a little bit more insight into working with variables.

And that way, we also have the test tab. And this is where all of your tests exist. So you can write tests such as like, you know, testing if your status code is 200. So in this case, you can see that you are getting a passing test. But this is your place for writing some a lot more dynamic scripts, and building some workflows.

So let's take a look at a little bit of our basic testing syntax. So here, you're going to take a look at this example where we're working with the PM dot test methods, which allow you to basically make assertions and write tests that validate whether or not certain parameters are met and whether or not certain timestamps are met.

So like I mentioned, pre request scripts are you and test scripts allow you to write API tests and build requests that contain some sort of dynamic parameter. The postman runtime is based on node j s. So it's using the chai assertion BDD syntax library, which allows you to recreate optimize readable and reusable tests. So in this case, when we're taking a look at the basic syntax test, you can take a look at the adding set and get values. So for example, here, I am setting this value back to red, if I send this variable, I have a test here that I am, you can send the name of the first test, which is testing the response, you can send the name of the second test. And then here I have a specific test that is validating some sort of string within my response.

So for example, I'm using p.m. dot response text to include the value red. So if I were to, for example, change this, I should be able to see a failing test, because it's not getting that assertion. So when it comes to testing within postman, what you definitely care about is being able to validate the right, the right values here. So to validate the data returned, you can use the p.m. dot response method object in a test. And then to create a test, you want to use the p.m. dot test function, which allows you to provide a name and a function which returns some sort of Boolean value of true and false, whether or not that test has passed or that test has failed. So this is kind of how you would want to structure your tests.

So here again, I am also taking a look at the expects syntax. So if you're trying to structure specific assertions, there's a variety of ways, depending on your logic and your reference term of how you might want to output that result. So for example, here, you might want to use an expects to see some sort of expectation. So in this case, it is expecting we're having a failed test, because it's expecting that your status code is 201 rather than 200. You can use, like, you know, for example, these are all parameters that are expected to fail just to kind of show you how the p.m. dot expect function works, which is kind of a function that is testing some sort of logic. So these are some basic syntax and test methods and functions. Of course, you can take a look at some of the snippets that we have available.

We have snippets here for basically, you know, response body contains a string. So like if I were to add some more snippets in here, I can take a look at some snippet here that shows that this is supposed to contain a specific string. I have snippets that are testing specific successful post requests. I have snippets for testing status code. And I also have some sort of schema validation snippet to validate my entire schema and all the various types that I might have available here. So I'll take a I'll give you a little bit deeper insight into what that looks like. But you have some of these snippets to help you kind of get started with a lot of your your tested and you can use these curated list of commonly used test code snippets to meet any of your specific environments.

So I wanted to kind of show a couple of ways to now kind of dive a little bit deeper into building a workflow. So once you have a deeper understanding of testing at the basic level, you can kind of build an entire workflow of tests.

So for example, here, I have my library API reference books. And I can use some of the workflow that I have available to kind of test for specific books. So in this case, I have a URL where I have an API that gets gets a library reference of various books that I might be interested in.

So here, if I take a look at some of the tests I have available, I am trying to get the first book. And I'm setting that first book ID as a collection variable. So if you if you see that I've tested this, you can see that that first book's ID is now set as a collection variable. So I can also use the console log to validate specific things.

So for example, here, I'm validating the genre of my first book. So if I use the console log, you can see that I am trying to validate one that one of my genres of my first book in my library includes the genre fiction. So you can see that that ID was saved and that genre was specifically saved. So I'm here once I have this genre, I'm able to write a test here that is expecting that my response includes that specific genre. And so here, I can see that I have a test that I want to validate that my body of my data includes the genre fiction. So as you can see, I can create a specific test to kind of, you know, set specific IDs, select the genre, and create some sort of like validation here.

So maybe one of the reasons why I have set my ID in my first test is because for my second request in my collection, I am actually getting a book by a specific ID. So here, you can see that I want to get that book by that, I want to get that first book and test that I'm able to get the first book in my collection because I want to test this API that allows me to get a book by a single ID versus getting all my books. So here, if I were to test, you can see that I am able to get that specific book by that specific ID. And I can test that my API works here as well. So I can, you know, validate here that we are able to get that book by that ID. And I have a test now that I have been able to test that shows that I can validate that specific book by that ID.

So as you can see, you're using variables and scripts from one request to another to build an entire workflow. So now if you have a POST request in here, where you are, you know, you're using variables for your book title, you're using maybe if you're trying to send some random data into your library. So for example, I'm sending a book called Intro to Algorithms as a part of my title. And I want my author just because I want to test my API to have a bunch of random author full names. And I want to write a couple of tests that are specific to my POST request. So for example, I'm here, I'm writing a test that is specific to, you know, my POST requests that equal 200 or 201. So if I send these, this API request, you can see that I have some test results that validate that API. And now when I go back to my GET books, I you can see that my first book was that Intro to Algorithms book that I had initially posted with my POST request, with that author, and it has its own ID. So you can see that my library workspace, or my library APIs are now being set into a specific API workflow.

So here again, I have a test to specifically test for that book, I can test my patch request, where I am, you know, adding a checked out element. And then I can, of course, so here, if I am patching that my checked out is true. And let's run back for that, I should expect that one of my books in here, maybe this is not the right ID, but it is checked out as true. So for example, this is taking the ID of the first book, which was this, one of these books here that I set up. And you can see that that checked out element is now true. And then of course, I can delete that book by that specific ID. And I can see that, you know, see the whole API CRUD lifecycle. So here we have gone through reading, writing, through reading data, writing data, deleting data, we've gone through all of the CRUD methodology of working with APIs and how to kind of test and validate using some of the test scripts and then using things like collection variables, getting and setting to ultimately build a workflow. And I wanted to share this blog with you all, because this blog is interesting in the sense that there's a lot of ways to build workflows in Postman. So the possibilities are kind of endless when it comes to working with Postman. You can, in this case, we were chaining maybe different requests. So you can take a look at like what it looks like to chain requests. So if I had all of these APIs, I can chain them by setting and getting variables. I can set asynchronous requests as well. So for example, I can use the pm.send request. So in this example, I'm sending another API within the API. So I'm sending multiple APIs within the tests of an API should show what it looks like to send asynchronous requests. And then ultimately, I can also loop over test using some sort of conditional logic as well. So here I talk a lot about the collection runner, which allows you to ultimately run your tests in a sequential way. So if we were to take a look at our library reference, which are all of those tests that we've written here. We can now take a look at the collection runner, which enables you to run a collections request in a specified sequence that allows you to test the functionality of your API. And ultimately, what it does is it logs your request as test results. And you can use scripts to pass data between requests and alter the request workflow. So let's take a look at what the collection runner looks like. So here, if I were to take a look at my test, there's this run button here. So in this case, I can set the order of my tests, and I can run these manually. I can set the iteration. And I can also set any specific delays. So here, it looks like you can see that each of these requests have been run. And you can see that all of the tests, you can see all of the pass and the fail.

So for example, if you wanted to view the summary, you can see which tests have passed, which tests have failed within your collection runner. And you can see ultimately, like how you can build an entire like test iteration within Postman. So with Postman, you can see like some of it logs exactly what times you've ran this test. And you can see all the tests that have passed all the tests that have passed all the tests that have failed. And you can also take a look a little bit at the results as well.

So we also have you know, within Postman, you can do a little bit of scheduled runs, performance testing. So for example, scheduled runs, they allow you to trigger your run. So for example, here, if I were to do a scheduled run, I can set a frequency. So like every minute, run all of these collections, you know, or every five minutes, run these collections and set these iterations and send an email notification drive. You can also run these by using the Postman CLI. So the Postman CLI is actually really useful when it comes to building a workflow and and running your specific collection on some sort of CI CD pipeline. So for example, if you wanted to configure that particular collection, and you wanted to run it on Jenkins or CircleCI, GitLab, TravisCI, you can set that at various different operating systems, and you can set various environments. So for example, here, I wanted to run this using my test environment, my test URLs, my test API keys, my test access tokens, or if I want to run this in a production environment or staging environment. So you you can set up entire CI CD CLI pipelines, and you can see that it sends the command here and it allows you to generate a Postman API key to to run that specific collection.

So those are some ways to automate your your use of testing, but the idea here is to understand how variables work, understand the basics of scripting, and then understand how you can build entire workflows. And so once you kind of have a deeper understanding of a lot of that, I wanted to show you a new tool called Postbot that has recently come out, and it's brand new to Postman, that is available at least on the free plan, which allows you to use some of our generative AI elements to write tests. So I wanted to first go off and introduce Postbot, which is our new AI assistant and allows you to use natural language to create tests within your workspace. So here I have a API, for example, that is getting some dad jokes. I can use Postbot, which is on the bottom to go ahead and add tests to this request. And you can see that it is adding all of the tests. For example, it's expecting to have specific properties, expecting for some things not to be empty, and you can see that you can also fix specific scripts to evaluate your tests here. So it's fixing specific syntaxes, and it's writing the test for you. So for example, you can, in this case with my library example, I'm going to delete all of this. I can use Postbot. So for example, I'm going to say, write me a test to test that one book. Okay, so you can see that it is generating that specific test. So I showed you what that looks like at a basic level when it comes to building test workflows, but you can also now use Postbot to generate some of these tests. Some of my favorite ways to use Postbot is to visualize some of a response. So for example, if I wanted to visualize this response as a table, you can see that Postbot is generating a table for me. So it is using some CSS to generate a table based on title and author and genre, and I'm using the pm.visualizer.set to basically construct that visualizer payload.

So ultimately, when I have my body, I can also visualize my data in a table as well. So this makes it a lot easier not only to take a look at the data I have available, but also to look at the visualization of that data that I might be interested in generating. So these are some ways to kind of take a look at Postbot. Postbot is a very interesting tool when it comes to testing, and it makes testing a lot easier for people. It provides even more of a template for people to get started. One way that I feel like is important, that Postbot is important is being able to like add a test for a schema. So like in this example, I'm using Postbot to test for a schema. So if I were to test for a schema as well, you can do a little bit more like schema type of testing where it is testing that your schema is specifically valid based on the various properties that you have available. And it's using like the TB4, you know, library to validate that schema. So this is also important when it comes to contract testing and aspects like that. So you can see that you have valid schemas as well.

When it comes to advanced testing, you know, there are a lot of things like contract testing, where you're, you know, testing for valid query parameters, testing for various arguments, checking for valid forms. And these are all, as you remember, all collections that we have, you know, got from our API collection template. So also when it comes to integration testing, like for example, if you have one API that is doing some sort of register, and then you have another API that is doing something else, and it's, you know, getting the token, then how do you integrate some of these APIs together and build some sort of integration test. So those are all very important in terms of the various different types of testing that you can do with Postman.

You can do mock data generation where you can generate some mock data. You can also do some performance testing as well that allows you to, you know, test for specific loads. And so since I'm working on the web UI, performance testing is available on the Postman client. So and then of course, you have like regression testing, which you know, you can vary, build those workflows and test some of these like verifications. So when it comes to testing, there's a lot of testing that can be done within Postman.

So performance testing enables you to simulate traffic, and you can simulate how your API behaves under loads. And, you know, of course, contract testing is testing schemas and contracts. And so there's a lot more that we can do in terms of testing with APIs. And so just going back to my original workspace, so for the workshop, not only does Postman, for example, I tried to show you contract testing example here, and then working with like collection workspaces, and then using mock servers to mock requests. And I showed you a little bit more about automation as well. I wanted to share as well that there are a lot more other protocols that Postman supports, such as WebSockets, GraphQL, gRPC, and MQTT. So when it comes to working with APIs, there are not only does Postman support REST APIs, but it supports other APIs and other forms of APIs that you can get started at SWIT. So like for example, if we were to look at a GraphQL API, you can use the GraphQL API to query some data. Along with that, we also have scripts and snippets. So we have some scripts to test before the query is sent, and then some snippets to test after the query is sent. Similarly with gRPC, we also have some scripting capabilities here as well. So there's a lot that you can get started with.

I wanted to share a couple of resources. So for example, our first resource if you wanted to take a screenshot or take a look at this link is for our Postman Intergalactic. So Postman Intergalactic is a series of educational trainings. So we just had a training about API testing beyond the basics, AI and automation techniques. We've also have some training for our VS Code extension, testing and developing gRPC APIs, GraphQL APIs, intro to security. So there's a lot of content that is available on demand and is also available when we do it live. It's our live workshops and workspace. So we are always encouraging others to take a look at Postman Intergalactic, which is a great resource for folks. Then we also wanted to share all of our Postman blogs, which is a place for you to take a look and learn about some of the newest things that are coming out of Postman. So for example, we have some blogs about how Postmanauts use Postman and how workspace squads use Postman. There's some blogs specifically about Postbot that I wanted to share, which Postbot is a tool that not only helps you test, but also writes documentation. So you can use Postbot to document your APIs. So when it comes to, for example, Postman, you have your main documentation for your workspace, but you also have documentation for each of your APIs here.

So you can use Postbot to generate some of this documentation as well to document all of your query parameter outputs, et cetera. So that's another useful thing. And then we have a lot more interesting examples of working with Postbot and testing. So for example, we have a colleague that used the Spotify API in Postbot to build an entire track result playlist and visualize maybe their Spotify, what Spotify comes out with every year, their stream, their most popular played songs, et cetera. So there's a lot of interesting ways to work with Postman aside from testing, but testing is obviously such a big aspect of Postman in itself.

We also have a couple of workspaces that kind of show you the different ways of writing tests. And then we have a skills level that allows you to get a deeper insight into your own skills with Postman, for example, what kind of experience you might have. And then we have the 15 days of Postman testing challenge, which goes through a lot of the things I've talked about today, understanding the API client, understanding version control, understanding how to debug, work with authorization, variables and scripts, API tests. So we have this entire 15-day challenge for testers that I encourage all to share.

So with that, I have shared quite a few different things, the learning, the community center, which is the Postman learning site, where you can get the documentation, Postman blogs. And then we also have the Postman Academy, which is here to help you level up your Postman skills as well. I hope this gives you a deeper insight into how you can go and work with Postman. I hope you were able to get a little bit of a deeper insight into the basics of testing, building workflows, working with collections, working with collection variables, and you're able to use that insight to go forward with your API testing practices. So with that, I'd like to say thank you for allowing me to share some insights with you all. And if you are interested in connecting with me, I am available at PujaMakes on Twitter and X. And I'm happy to help answer any questions or provide any deeper insights into the world of Postman. So with that, I'd like to end the stream and wish everyone some happy holidays as well. So hope everyone has a great rest of the year. And I look forward to connecting.