I'm trying to write unit tests for my HTTP service. My service interacts with another remote HTTP service, and I'm using using q-io/http for that interaction.
I would like to use something like the nock package to mock my calls to the remote service, but q-io/http does not seem to be compatible with nock (I'm assuming that this means that the request module is not actually used under the covers of q-io/http as I'd hoped).
Are there any other approaches to mocking q-io/http requests? There does not seem to be an http mocking capability included in Q like there is for files.
It turns out that q-io/http does indeed use the standard request module under the covers, and subsequently, it is possible to use nock with the q-io/http module.
For me, the problem was that nock was not matching my requests, and the exception was getting swallowed up in a catch. Using the nock log(console.log) mechanism made the matching problems obvious:
nock(documentUrl)
.delete('/state')
.reply(204, {})
.log(console.log);
Related
I'm writing integration tests for an API in NodeJs that publishes to Google PubSub topics. I don't want to really trigger those external messages in testing environment, so I need some kind of mock.
Since it's an integration test, I think the best approach would be to intercept external network calls to the pubsub service, returning a mocked response.
I tried using nock for this, but it didn't work. I think maybe because google's lib implementation is over gRPC / http2 (?)
Is there any solution to this or a better approach? What am I missing?
Thanks!
The HTTP client built into Node.js doesn't seem to support pipelining requests. However, it occurred to me that it may be possible to create an Agent that sets up pipelining in the background. There may be issues getting the response data back the way it should be, but perhaps the Agent could fake out some socket objects to make the HTTP client work like normal?
Has this been done? Alternatively, is there an alternative HTTP client that is a drop-in replacement for the main that supports pipelining? (Ultimately, I'd like to use it with the AWS SDK, so it needs to be compatible.)
Supposed I have a middleware for Connect and / or Express. What's the best way to unit test this middleware?
Of course, I can set up an http server in the unit tests, and load the middleware into this. But supposed that I want to test startup behavior, I need several http servers, which soon gets complicated and unclear (think of using a new port in each single test).
Is there a better way, or is testing it inside a real server the best one can come up with?
supertest does the job, as pointed out by SLaks in the comments.
If to call own api for building the website is a good practice.
Which is the best way to call own api on the same server in a nodejs application?
simply calling the api-methods
using socket.io with emit() and listen it with .on('event', function(){})
install jquery on the server and use the ajax call
or not use at all the own api and rewrite the methods
i'm just confusing. Hope someone can clarify me on this.
If you need to call own API from another process it would be good to use some messaging protocol. ZeroMQ sounds like perfect fit here. It allows to create different patterns of communication between different services in internal networks, and communicate in different ways. Simplest example is Request > Response pattern that is similar to HTTP requests. And it might be a good start point.
Remember that if you using routing system within express, then ZeroMQ solution will not utilize that, it would be able directly communicate, not through HTTP interface. It is much more efficient as well, as HTTP has unnecessary overhead especially for internal communication.
If you still want to use express routing then your option would be to use http.request, which behaves very similar to curl or $.ajax. This function makes HTTP requests, so you can reuse your express routing system.
I'm working on an application that relies on data that the browser sends within the HTTP headers (and there's no way around this). This also happens to be my first time working with something node.js based, so it's very likely I'm completely missing something simple!
Basically what I want to be able to do is call a method on the server from the client, and in that method read the HTTP headers that the client sent.
Meteor doesn't yet provide a supported API for serving HTTP from your app. This is intentional: in the not-too-distant future, your app server is likely to not be just a single process directly serving end users, but an arbitrarily parallelizable service behind a proxy tier. So we'll need to provide a supported API for responded to HTTP requests (REST, eg) that continues to work in such a setting.
Are you sure it needs to be HTTP and that you can't just use a Meteor method?
If you really need to accept direct HTTP requests now, take a peek at how packages/accounts-oauth-helper/oauth_server.js uses __meteor_bootstrap__.app to hook into the Connect middleware framework. This will work for now, but we don't promise that Meteor will always be powered by Connect :)