Working an application in Vue.js with TDD — An extensive guide for people who have time — part 4
Testing our API request service
This is the fourth in a series of articles:
- Part 1: Setup and the first test
- Part 2: Continuing the UserView
- Part 3: Testing the store and the rest of the presentation components
- Part 4: Testing the API request service
- Part 5: Adding and testing with third-party dependencies
- Part 6: Overview — 26/11
If you want to read it in pt-BR, check it out here.
First of all, I’m really sorry for the delay to deliver this part, I just could not organize myself to launch the article last week 😅, but let’s get down to business.
Last week we finished all the tests of our components, and we did it all integrating with the store, wich probably was the most extensive and important part.
Let’s now go to the last part of the application that needs to be tested, the service responsible for handling Github api requests.
Testing our API requests service
Here, there is our last test. The only difference from what has been seen so far is using a new dependency, which we ended up installing in the beginning of the project, the nock.
Basically, this library allows you to test http requests in an isolated way. In this case, we can specify urls and in case a request is made for it, nock will intercept it and treat it the way you’ve specified.
In our case, from line 11 we are making nock to observe any GET request for the url: https://api.github.com/users/:username it will intercept this and
return an answer of status 200 with our expected user (our fixture).
Next, we call our service method passing our user and me make a flushPromise to guarantee that all the promises will be solved from this point on.
For the asserts phase, we want to guarantee that our service result is our userFixture, guaranteeing this way that the request for the expected URL has been made, which we are mocking with nock.
Finally, we want to guarantee that the mocked URL in nock has been called.
Our test is going to fail as we don’t have any kind of implementation yet. Let’s start.
Finally, we have our service to make the requests.
We make use of the axios, a library that helps us make the HTTP requests.
On line 4, we create an axios instance to make requests for the Github API.
The adapter we passed as configuration is necessary so that we can use axios with nock. This allows us to customize the way axios deals with the requests, so then nock is able to intercept this requests.
On line 10, we have our method that gets our username, returning a GET request for API of Github users.
On line 13, we get the requests response and return the property data of the request. I’m doing this here because axios changes the result and encapsulates the response in that property.
This way, we complete all the tests of our application.
Let’s see how it is?
Now we can finally see the result of our job. Run:
npm run serve
What are we seeing?
Absolutely nothing! But… of course, we need to create a route for our component 😆
Done. Now, that’s it:
Remember that we can also test the routes. We can create a test to guarantee that we have the expected routes together with the guards, in case needed, but we are not going to do this right now.
But with this we got to create a full application without seeing it. And what’s best, we have the main parts fully covered by the tests 😍
Overview
In this fourth article, we did:
- We tested the service responsible for making requests to Github
- We finished our application 😃
I recommend if you have interest to read the third party repositories used in this application:
Because there are a range of features that we can do with these libraries, and also do not limit to them, there are other libs that do this kind of job, like: jest-axios-mock.
Also as a warning, this way of testing this type of service will not replace integration and e2e tests, we are garanteeing here that the application works since the api is returning what we expect, if someday the Github API leaves the air, change the address or change the response format (this is extremely wrong), our application will break.
Be aware that next week we will be adding a third party component library and update our tests to use it.
Thank you very much for your attention and I apologize again for the delay 😅
If you liked, please click on the 💚, and any questions, suggestions or corrections feel free to send me a message, I thank you very much 😄.
My Twitter: @DKuroski
See you next week 😄
