Most of the API testing I am doing at this point is exploratory testing. Currently the area I’m working in does not have a lot of test automation on the APIs. We have developer level unit tests in place on the actual implementation of the APIs, but we don’t have many regression tests that run the APIs externally.
The tools I currently use for exploring APIs are largely a mixture of Postman and Python. I have used Postman to get in and figure out what an API looks like and the basics of what it can do. Then when I want to dive deeper and perhaps throw some interesting probes at it, I’ll dig in with the requests module in python. I also use Postman to document the API so that we have a shared references for what it can do and so that I have something to come back to when things are changing. One other thing I do is use Postman or SoapUI to make mock servers so that I can do front end testing of the components.
Python can also help with doing front end testing. For one of our components we have a bunch of static ‘demo’ data that we can use. Of course that data can become stale over time and so we need to occasionally refresh it. I use python to automate this process. It can make the request to the API to get the new data and then do the cleanup need to make it work as static files.
I have also experimented with a few other tools and hope to flesh out a bit more automation as we move forward, but for now that is my API testing tool set.
Photo by Bernard Hermant on Unsplash
So the video I am going to share today isn’t explicitly about testing an API, but if you want to test something you should really understand it. I think this video is a great introduction to understanding APIs and thinking about how they work.
Note that this video mentions the Postman addon, but you will probably want to use the desktop version of Postman now.
Hope you enjoy it.
Photo by Jakob Owens on Unsplash
I didn’t have a lot of time to look at this yet, but I started poking around with Apiary
It looks like a pretty neat little tool. I’m not sure at this point if it is what I need for the work I am trying to do, but I think I will return to it to dig in a little more.
Testing needs to be woven throughout the software development process and I think tools like this can help make that a reality. So often we thing of testing as a separate column on a kanban board – something that comes after development – but we need to think of it as an integral part of the process. Having tools that let you think about testing right at the design stage is very important and it looks like there is potential in this tool that could make that a reality.
That is something I’m excited about and so I will continue to look into this and see if it indeed something we can use to move quality forward at our company!
Photo by Mantas Hesthaven on Unsplash
Today’s challenge is about explaining mocks, stubs and fakes.
I don’t know if I can pull it off.
The problem is, different teams will use these words in different ways. I don’t think it makes a lot of sense to argue about what exactly each of them means and how they are distinct from each other, but there is some value in at least understanding the general idea that these terms are meant to communicate.
In the broadest terms, when we talk about these things we are talking about something that is a substitute for a piece of production code. For example, we might have a database that stores some values. When running tests though, it might expensive to go retrieve those values many times, so instead we might make a local text file that has a few of the values we care about hard coded into it and just use that instead of the ‘real’ databases.
No matter what term we are talking about – mocking, stubbing, faking, etc. – what we are doing is using something that is not the production code to simplify in some way what we are doing for our tests. This helps us isolate things to just the specific part of the code we are interested in and can be used in some really powerful ways.
I wouldn’t worry too much about understanding in an absolute sense what these various terms means. What matters in figuring out what they mean in your context. How do the members of your team use these terms? What do they mean by them? How do the tools that you use talk about these things and what do they mean by it? Understanding how the terms are used in the contexts in which you work will help you better communicate with those that you work with.
The idea of mocking, stubbing or faking something is a very powerful testing concept and well worth taking the time to learn how to do, but don’t get too caught up in the specifics of the terminology.
Photo by Jelleke Vanooteghem on Unsplash
What skills does a team need to succeed with API testing?
Let’s start with what I think is the most obvious one. Testing skills. I’ve said this before, but API testing is, well, testing. You need to approach it with all the same skills and mindset you would approach any testing task.
I think you also need someone who understand or can learn some good API testing tools. Effective API testing often involves diving deep into the API and the better you understand tools that can help you do that, the more effective you will be in your testing.
Creating a valuable API, also means you need someone who deeply understands the business or customer need for this API. The vast majority of API bugs I find are related to the API not providing the information the business needs, or providing it in ways that are difficult to find, use or understand. This does fall under general testing skills, but it is worth mentioning again as it is vitally important that APIs actually do what the business needs out of them. Sometime we can forget that when we are deep into something technical like an API, but we (should) only write these to help drive the value we are after. If they aren’t doing that, they need to be changed.
On last thing I will mention here is security. Security is important everywhere in the software development process, but I think it is especially important in APIs. If I were trying to break into a site or service, I would start with the APIs. They are designed to be scripted, which means you can use a lot of algorithmic and brute force attacks to try and break into them. You definitely don’t want to forget about security and authorization when testing an API.
Photo by rawpixel on Unsplash
There are so many tools out there for testing APIs, that it can be overwhelming. I use a few different tools, depending on what I’m trying to do. One thing that can be difficult in API testing is figuring out what routes are available in your API. This is especially true if the API is poorly documented or does not including any self-documentation.
There are a number of different tools out there that will help you discover what calls your API is making, but do you want to know what my favorite tool is for this?
The developer console.
Yup, that’s right. The developer console. There are tools like Wireshark or feature built into tools like Postman that let you ‘watch’ network traffic and figure out API calls from there, but I find that often the API calls are right there in the network tab of your console. It can be quick and easy way to get the info you need to get you started.
Photo by Markus Spiske on Unsplash
Today’s challenge involves reading and sharing a blog post. I read a lot of blogs and I find it to be a great way to learn and stay current with thoughts in the industry. I’ll actually share a couple of posts. The first one is more of a reference. The Web API Checklist gives a lot of useful things to think about when testing and API and is a great reference
Another great resource, if you are getting started with API testing is Katrina Clokie’s API Testing Pathway. She gives you a lot of guidance on this without specifying everything you do. I’ve found this to be a great resource and would highly recommend it to anyone interested in learning more about API testing.
What blog post or resources have stood out to you?
Photo by Autumn Mott Rodeheaver on Unsplash