In November I took part in API testing Challange.
I was posting my answers on Facebook. This post is a little-edited compilation of them. Originally I was intending to do missing days here, but my end of the year schedule is tighter than expected so I won’t be able to do it.
Day 1 „Define what API testing is”
First, we need to explain what Application Programming Interface aka API is.
In big simplification, it is a way to allow the programs to talk to each other in a more „machine-friendly” way.
This interface compared to UI is not „customer-facing” so they don’t need to be human readable.
Usually, an application that uses API will take care of translating User inputs to a form acceptable by API and vice-versa. Of course, its results may not be presented to you only used for other calculations in the application.
Another important fact is that API is not limited to web – yes it is most populare type but there are other for more examples you can check wikipedia entry.
So Testing API is testing this Interface its if its inputs and outputs behave as expected. Plus if our own application Layer uses API it allows us to check the logic of an application in separation from our UI layer which may not be developed yet.
It is important to note that API testing is not the same as integration testing, granted quite often it is the easiest way to perform those test but it is not only one.
Of course, since API is not „human-friendly” testing it requires more technical experience. It is not necessarily harder to testing via UI only harder to get used to.
Day 2 How would you approach API Exploratory Testing?
I think that is mostly good about API is that they require contract how they will work and what form they will return data.
Which is a great starting point for testing,
Your first Test Idea / Charter should be checking if API is behaving as expected.
Then you can design your next test idea based on what you observe.
If you are testing Web API tool that may help you is https://insomnia.rest/ Postman is also good but for Exploratory testing, Insomnia gives you more freedom.
Day 3 Begin reading an API testing related book and share something you’ve learnt by day 30.
Unfortunately, I have my own book schedule and I won’t change it but I will recommend a book that I read last year:
https://leanpub.com/testrestapi
Alan Richardson did a great case study of how to test API.
But the most important lesson for me wasn’t about API. It was the importance of home turf. You need to have your pet application which you use for experimentation, you know it so well that you feel comfortable taking risks you wouldn’t be able in your day to day testing.
Krzysztof Jadczyk had also compiled nice list of books about API.
Day 4 Share a resource on HTTP and how it works.
Lately, when I need to check something I go here:
if I need more in-depth info I check w3 standard.
Just be warned it is not easy to read.
Day 5
I am going to rephrase challenge today to „Contribute to the list of publicly available APIs, that we can utilise to practice API testing.”
I will give you a recommendation, not of an API but place where you can play with #swaggerhttps://petstore.swagger.io/ It is a good starting point to see its usefulness.
Day 6 Read and share an interesting blog post on API testing
This API challenge is too much concentrated on web API – and today I am going to embrace it fully with this article.
Yes, it is about integration testing, but in my opinion, it is an article that is more important than any API testing article I have read. And yes it is 4th time I link to it
Day 7&8 Skipped
I was on Belgrade Testing Conference.
Day 9&10 Done as one
Day 9 Share some tools we can use to discover what API calls our applications are making.
Day10 Share your favourite API testing tools and why
Why? Because in both cases my recommendation is the same
Fiddler.
It allows you to listen to all calls going from your computer (for some it need s additional setup) you can even use it to listen to
Day 11 Learn about different types of API’s, share your findings.
I have already talked about it in day 1.
But In the meantime, I found this great presentation that explains other types of API
It is short and to the point -definitely must read!
Day 12 Share what skills a team needs to succeed with API testing.
There is a long list of skill that can be useful skills for API Testing,
But I want to mention a Basic Skill: Reading Comprehension.
We need it for everything, but in the case of API and any Technical documentation without Comprehension, you won’t get too far.
Day 13 Contribute to the list of API automation tools over on The Club and share your experiences with using them.
For Web API Automation I like to use Rest-Assured – it has easy setup and lots of tutorials and documentation. Plus if the properly used test in it is easy to read.
Day 14 Compare and contrast mocking, stubbing, and faking
I love an explanation from this article.
I am going to quote the short explanation:
„Fakes are objects that have working implementations, but not same as production one. Usually, they take some shortcut and have simplified version of production code.”
„Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects.”
„Mocks are objects that register calls they receive.
In test assertion, we can verify on Mocks that all expected actions were performed.”
Days 15-18 Skipped
I was on Testwarez during this time.
Day 19 Find and share a useful video about API testing.
I think you may have noticed I am EvilTester Funboy in case of API testing so here is another his video https://www.youtube.com/watch?v=NrDHvu5ewLo
Day 20 Share all the tools, frameworks, and libraries currently used in your API testing along with why
I have talked about it in past Rest-Assured for Java and RestSharp for C#.
But I am currently experimenting with Pact.io for contract based testing and Love idea behind it I have no opinion on tool yet.
Day 21 Skipped
Day 22 Share your biggest frustration with API testing!
API is usually treated as WEB API even this challenge does that
There are a lot of other APIs and finding info on how to test them is hard. Your best option is experimentation.
Day 23 Status codes are often misused, share your favourite resources for understanding status codes.
There is the old saying “Read the F*cking Manual” so here it is.
Day 24 Share the best API bug you’ve found.
It’s more authentication bug. But in one system I tested sending any authenticated request allowed to access to “personal files” of other users.
Day 25 Security is important in APIs, how are you security testing your APIs?
I was little talking about it in the previous day I am checking how they handle authentication.
Plus currently, in my company, there is a great Security Community under Michał Buczko – Test Consulting.
So next time I will be checking API I will ask them for advice on security.
Day 26 Demo some of your API testing to other members of your team.
I am in midle of preparation workshop for testing webservices so I am kinda doing that point from july…
Day 27 What advice would you give to someone looking to get started with API testing?
My suggestion is not only for API but for anything new you want to try:
Check out
and do Kolb Learning Style test.
This will help you discover which way you learn best. And then using that new knowledge start doing the new task.
Day 28 Performance is key to a good API, how are you performance testing your APIs?
I admit performance testing is one of my weakest skills.
You can’t be skilled in everything and I consciously decided to not invest much time in performance testing skills.
Having said that it doesn’t mean I have none.
There is one aspect of performance that is easy to check how the system behaves when it has already lots of data in DB. Is it still able to work fast or is it slowing down?
Day 29 Browser developer tools have lots of API testing features, explore them and share your findings.
As much as I prefer fiddler the network tab in chrome developers tools is also a good way to see API call going under the hood. (just select XHR option it will remove lots of noise)
Day 30 – Skipped
And that’s all
I have done less days then I’ve planned but still it was good exercies for refreshing my API knowlagde.
And what about you did you participate? Have you learned something intresting?