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
Today’s challenge involves sharing publicly available APIs that you can use for testing. In putting together recent courses on API testing I have spent a bit of time looking for APIs like this. The Ministry of Testing Club has a thread on sites you can use for practicing testing which was very helpful to me. There is also another thread on the MoT Club that directly asks about useful real world APIs to test against. If you are looking to practice API testing those are great places to start.
There are a lot of good resources for practice in testing GET calls, but it is a lot harder to find ways to test POST, PUT or DELETE calls. This is of course understandable, as those calls change things in the application, meaning it is hard to keep the application consistent for each user.
In recognition of this, I have tried to create some API Testing Challenges that can be used to learn testing. So far they are pretty basic and just at the starting stage, but if you want to try them out, you can go ahead and get them on Github here. They are pretty rough at this point, but feel free to use them if you want. Feedback is always appreciated as well of course!
Testing is something that it hard to learn without doing it, so I would encourage you to follow up on some of these resources. Try to ‘test’ some of the sample APIs out there and see how much you grow as a tester!
Photo by Jordan Sanchez on Unsplash