Why we need nock to do http request unit test? - node.js

Below is the sample code from redux document
describe('async actions', () => {
afterEach(() => {
nock.cleanAll()
})
it('creates FETCH_TODOS_SUCCESS when fetching todos has been done', () => {
nock('http://example.com/')
.get('/todos')
.reply(200, { body: { todos: ['do something'] }})
const expectedActions = [
{ type: types.FETCH_TODOS_REQUEST },
{ type: types.FETCH_TODOS_SUCCESS, body: { todos: ['do something'] } }
]
const store = mockStore({ todos: [] })
return store.dispatch(actions.fetchTodos())
.then(() => { // return of async actions
expect(store.getActions()).toEqual(expectedActions)
})
})
})
Why we nee to use nock for this unit test?
I did not see any where use the data from nock in this sample code.

Nock is used to mock http requests - if you mock http request it means that your code doesn't perform real http requests to the server.
Nock (and any other http mocking library) overrides native http requests methods so that real http requests will be never sent. It has many benefits - for example you don't have to wait for actual server response because mocked request returns response in no time and of course your test are independent of server. You can focus on testing application code and don't worry about server - even if server doesn't work you test can be run.
You don't have to explictly use data returned by mocked request if you don't need to test it - the main reason of using nock in your code sample is to prevent actual http request to the server that FETCH_TODOS_REQUEST action would normally sent. Besides, even if mocked response data is not explicily used in tests it's probably used in the application code (probably FETCH_TODOS_SUCCESS action expects todos array to be returend) so you have to mock response data so that your application gets data it expects.
If nock wasn't used the test would take much more time because real http request to the server would be sent.

Mainly because in this test we're interested in the actions that get produced by actions.fetchTodos(). This action will make a call to the /todos endpoint, thus returning actions with some data. Since we're just interested in the data contained in the actions, we just mock it.
Nock internally intercepts the real fetch call to /todos and returns a successful 200 code, making it possible for the redux store to continue.
The data you're looking for is
{ todos: ['do something'] }
This is mocked and also expected later on

Related

Trying to spyOn a response inside a fire-and-forget method with jest

I'm working on a project in node.js where I'm setting up contract testing
So I want to test my API requests and response
here is the method I want to test
import rp from 'request-promise';
const foo = async () : Promise<void> => {
await rp(options).then(resp => {
return resp;
})
}
here in my test I want to check the resp (which will be provided by the pact when running the test)
The problem is I do not know how I can capture this variable to check it...
I've tried to use spies with no success and a mock won't help...
import requestPromise from "request-promise";
const response = jest.spyOn(requestPromise(options),"then")
await foo()
expect(response).toReturnWith({test:"test"})
I also tried to spyOn requestPromise() "post"
but no results
Is there a way to test this ?
It's not clear what you're trying to attempt here. You mention Pact but there is no use of it in your example.
Why do you need to spy on the request at all? Just return something from foo itself (instead of void) and assert on the response.
If you're using Pact, it will do all of the http request checks for you. And ensure the request was made.
You then just assert on the response.

Error: Can't set headers after they are sent because of res.?

I'm trying to set up a method that is called with Shopify's webhook. I get the data and I'm able to store with a fresh server but I get "Error: Can't set headers after they are sent" returned in the console. I believe this is because I'm calling res twice. Any ideas on how to structure this better?
This is my method:
function createProductsWebHook(req,res,next) {
//if(req.headers){
// res.status(200).send('Got it')
// return next()
// }
res.sendStatus(200)
next()
const productResponse = req.body
console.log(productResponse)
const product = Product.build({
body_html: req.body.body_html,
title: req.body.title,
});
product.save()
.then(saveProduct => res.json(saveProduct))
.catch((e)=> {
console.log(e)
});
}
This occurs because the middleware, createProductsWebHook(), is called first when a request is received, which then sends a 200 status code response, res.sendStatus(200). Then in, in the same middleware function, product.save().then(...) is called. save()’s callback function attempts to send a response too – after one has already been sent by the very same middleware – using res.json(saveProduct).
Key Takeaway
Middleware should not send the response; this defeats the purpose of middleware. Middleware's job is to decorate (add or remove information, i.e, headers, renew some auth session asynchronously, perform side effects, and other tasks) from a request or response and pass it along, like a chain of responsibility, not transmit it – that's what your route handler is for (the one you registered your HTTP path and method with, e.g., app.post(my_path, some_middleware, route_handler).

How can I put an Express REST layer on top of an Apollo GraphQL server?

I'm looking into putting a REST layer (using Express) on top of a GraphQL server (Apollo Server v2) to support some legacy apps. To share as much logic as possible, the REST endpoint should ideally wrap a GraphQL query that I'm sending to the GraphQL server, and be able to do small modifications to the response before sending the response to the client.
I'm having trouble figuring out the best way to query the apollo server from the Express routing middleware. So far I've explored two different solutions:
Modify the request from the REST endpoint such that req.body is a valid graphql query, change the req.url to /graphql, and call next(). The problem with this is that I cannot modify the result before it's being sent to the client, which I need to do.
Calling the /graphql endpoint with axios from the routing middleware, and modify the response before sending to the client. This works, but feels to me a bit hacky.
Do you have other suggestions, or maybe even an example?
I believe the solution 2 is okay to implement.
I've made a similar implementation, but in my case, a GraphQL service fetches data from another(multiple) GraphQL service(s).
And somewhere down the line I did something like this:
export type serviceConnectionType = {
endpoint: string
queryType: {
query: Object // gql Object Query
variables: {
input: Object // query arguments (can be null)
}
}
}
export async function connectService(params: serviceConnectionType) {
const response = await fetch(params.endpoint, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(params.queryType),
})
if (response.status === 404) {
console.warn('404 not found')
}
return response.json()
}

Sinon fake server not intercepting requests

Trying to use Sinon for the first time because of its fake server functionality that lets me stub an API response. Test itself is written for Mocha
However, the fake server doesn't seem to be intercepting the requests.
Code:
describe('when integrated', function() {
var server;
beforeEach(function() {
server = sinon.createFakeServer();
});
afterEach(function() {
server.restore();
});
it('can send a message to the notification service', function() {
server.respondWith("POST", new RegExp('.*/api/notificationmanager/messages.*'),
[200,
{ "Content-Type": "application/json" },
'{ "messageId":23561}'
]);
var messageOnly = new PushMessage(initMessageObj);
var originalUrl = PushMessage.serverUrl;
messageOnly.setServerAPI("http://a.fake.server/api/notificationmanager/messages");
console.log("fake server is: ", server);
messageOnly.notify()
.then(function(response) {
messageOnly.setServerAPI(originalUrl);
return response;
})
.then(function(response) {
response.should.be.above(0);
})
console.log(server.requests);
server.respond();
})
});
For reference, PushMessage is an object that has a static property serverUrl. I'm just setting the value to a fake URL & then resetting it.
The notify() function makes a post message using request-promise-native to the serverUrl set in the PushMessage's static property.
What seems to be happening, is that the POST request ends up being properly attempted against the URL of http://a.fake.server/api/notificationmanager/messages, resulting in an error that the address doesn't exist...
Any idea what I'm doing wrong...? Thanks!
There have been several issues on the Sinon GitHub repository about this. Sinon's fake server:
Provides a fake implementation of XMLHttpRequest and provides several interfaces for manipulating objects created by it.
Also fakes native XMLHttpRequest and ActiveXObject (when available, and only for XMLHTTP progids). Helps with testing requests made with XHR.
Node doesn't use XHR requests, so Sinon doesn't work for this use case. I wish it did too.
Here's an issue that breaks it down: https://github.com/sinonjs/sinon/issues/1049
Nock is a good alternative that works with Node: https://www.npmjs.com/package/nock

What is the correct way to test Webhooks?

I have a ReSTFul API in Meteor. I use hooks from Mandrill, Stripe, and other libraries to update a collection.
Router.route('/mandrill/message_rejected', { where: 'server' })
.post(function () {
var request = EJSON.parse(this.request.body.mandrill_events);
var rejects = _.map(_.where(request, {
event: 'reject'
}, {
return object.msg.email;
});
Meteor.users.update({
emails: {
$elemMatch: {
"address": {
$in: rejects
}
}
}
}, {
$set: { status: 'rejected' }
});
this.response.end();
});
My question is; how can I automate tests for this? The request is supposed to come from Mandrill. Is there some way to test webhook messages in a consistent way?
I use Mocha (although you can use other testing frameworks as Jasmine).
I combine the tests with the superagent library that allows you to perform HTTP requests.
The next part does the trick: set up a log and store the received JSON from Mandril or other hooks that you receive and build a library (or fixture) of incoming responses.
Then you can build up the different cases that you need, for example:
Removing an expected field
Sending duplicates
And so on
Making this method consistent requires that you spend time thinking about what hooks you expect to receive, reading the documentation to evaluate if a case you are thinking on is not possible and so on.
I'll recommend you to keep the log of received hooks to improve your tests over the time.

Resources