API testing with WebdriverIO and swagger.
In the past couple of weeks, I saw some people on Twitter talking about API testing. Some of them said it’s not that easy to do and wanted to learn more about it. Also, others were sharing different ways to do it, using UI testing tools.
So as my two cents, I will share another way to test your API, using WebdriverIO and swagger!
All you need is Node installed and a beautiful and well-documented API using swagger. Easy, right?!
To start, we’re going to follow the steps described in the amazing WebdriverIO docs.
Just install it with npm install @wdio/cli and run the config command npx wdio config, then answer the questions as below:
Done, you have the tool ready and set! It is up to you to add PageObjects, Cucumber, and change any other item from the configuration menu. I have picked those because I like to have a lot of files to maintain!
By the way, I am using the ServeRest API, created and maintained by a colleague from the Brazilian QA community Paulo Gonçalves. It is a great place to check your API testing skills, it is in Portuguese, but if you don’t understand it, Chrome can always translate everything so no worries about that.
Then let’s start with the automation itself (I’m adding screenshots from the code so you can’t copy/paste these awesome examples).
Step 1: Map the needed UI elements and actions in your PageObject files.
Step 2: Change your cucumber steps, so they make sense in your context.
Step 3: Change the Feature file to contain the needed test cases.
Step 4: Repeat it over and over again until you have all tests there.
Well done! You can now test your API in a fast, useful, and reliable way!
But NO!
If you reached this point of the article without feeling annoyed, here’s the deal: you SHOULD be worried about that! Why would someone use a UI testing tool to test API scenarios?
I saw some people using Cypress to test API’s and I know it is not as I described above. Endpoints are called with cy.request(method,url,body) and don’t use UI elements but still, why would you use a tool that loads everything you need for a UI test and open a browser instance just to call endpoints?
But hey! Aren’t requests useful for UI tests? They indeed are! There are a lot of scenarios where you can get value from API calls during your UI tests. If you are creating a new account and then you need to verify your email address, but you don’t want to open your email client and do that, call /verifyEmail/:userId and get it done quickly!. It’s really helpful when you would need to leave your application to do something in another place and don’t want to waste time.
I won’t extend more on the reasons, as it’s already explained in this article from my lovely friend Leonardo Galani ❤️. But mainly, when we automate things we’re trying to get the fastest feedback possible, so let’s use the fastest tools.
For sure, while writing this article, I exaggerated to show how weird it is and used a lot of unnecessary stuff like POM and Cucumber (please don’t), but it’s just to show you one thing: Don’t use those tools just because you can, do because they bring the needed value.
The video below illustrates how it feels to use UI testing tools for API testing:
In my next post, I will talk more about API testing, but this time using the right tools!
