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.
Related
I've got a simple FeathersJS server. I want to change certain things in its config without restarting it, such as disallow creating new users.
So, basically, I want to change a couple of variables at runtime.
It definitely sounds like something that's got complete solutions written somewhere.
My thoughts are to expose a callback that, according to its args, changes the variables of interest, then call the callback with something like inquirer or expose WebSockets that execute the callback accordingly.
Please tell me how to best solve this problem, and - if possible - point me to some existing solutions as well.
To change something inside your nodejs process from outside the process, you need to expose some external connectivity that can make the change for you. There are an infinite set of choices, but a webSocket/socket.io server or an http server are probably the most common.
If this is typically just a transaction, not a whole sequence of changes, then a simple http server on a port that is not accessible from the outside world is probably the most appropriate way to do this. You then just create routes on the http server that accept the desired changes and the code in the routes themselves changes the internal variables accordingly. If you chose some other interface such as a webSocket or socket.io server, the concept would be the same.
I'm very new to Node.js, so I might just not be getting it, but after searching quite a bit, and trying a few different solutions, I am still not able to find a decent way to mock API responses using Node for acceptance testing.
I've got a javascript app (written in elm actually) that interacts with an API (pretty common, I imagine), and I want to write some acceptance tests... so I setup WebdriverIO with selenium and mocha, write some tests, and of course now I need to mock some API responses so that I can setup some theoretical scenarios to test under.
mock-api-server: Looked pretty nice, but there's no way to adjust the headers getting sent back from the server!
mock-http-server: Also looked pretty nice, lets me adjust headers, but there's no way to reset the mock responses without shutting down the whole server... !? And that has issues because the server won't shut down while the browser window is still open, so that means I have to close and relauch the browser just to clear the mocks!
json-server: Simple and decent way to mock some responses, but it relies entirely on files on disk for the responses. I want something I can configure from within a test run without reading and writing files to disk.
Am I missing something? Is this not how people do acceptance testing in the Node universe? Does everyone just use a fixed set of mock data for their entire test suite? That just sounds insane to me... Particularly since it seems like it wouldn't be that hard to write a good one based on express server that has all the necessary features... does it exist?
Necessary Features:
Server can be configured and launched from javascript
Responses(including headers) can be configured on the fly
Responses can also be reset easily on the fly, without shutting down the server.
I hit this problem too, so I built one: https://github.com/pimterry/mockttp
In terms of the things you're looking for, Mockttp:
Lets you start & reconfigure the server dynamically from JS during the test run, with no static files.
Lets you adjust headers
Lets you reset running servers (though I'd recommend shutting down & restarting anyway - with Mockttp that takes milliseconds, is clear & easily automatable, and gives you some nice guarantees)
On top of that, it:
Is configurable from both Node & browsers with identical code, so you can test universally
Can handle running tests in parallel for quicker testing
Can fake HTTPS servers, self-signing certificates automatically
Can mock as an intercepting proxy
Has a bunch of nice debugging support for when things go wrong (e.g. unmatched requests come back with a readable explanation of the current configuration, and example code that would make the request succeed)
Just to quickly comment on the other posts suggesting testing in-process: I really wouldn't. Partly because a whole bunch of limitations (you're tied to a specific environment, potentially even specific node version, you have to mock for the whole process, so no parallel tests, and you can't mock subprocesses), but mainly because it's not truly representative. For a very very small speed cost, you can test with real HTTP, and know that your requests & responses will definitely work in reality too.
Is this not how people do acceptance testing in the Node universe? Does everyone just use a fixed set of mock data for their entire test suite?
No. You don't have to make actual HTTP requests to test your apps.
All good test frameworks lets you fake HTTP by running the routes and handlers without making network requests. Also you can mock the functions that are making the actual HTTP requests to external APIs, which should be abstracted away in the first place, so no actual HTTP requests need to take place here as well.
And if that's not enough you can always write a trivially simple server using Express, Hapi, Restify, Loopback or some other frameworks, or plain http, or even net module (depending on how much control do you need - for example you should always test invalid responses that don't use HTTP protocol correctly, or broken connections, incomplete connections, slow connections etc. and for that you may need to use lower lever APIs in Node) to provide the mock data yourself.
By the way, you also always need to test responses with invalid JSON because people often wrongly assume that the JSON they get is always valid which it is not. See this answer to see why it is particularly important:
Calling a JSON API with Node.js
Particularly since it seems like it wouldn't be that hard to write a good one based on express server that has all the necessary features... does it exist?
Not everything that "wouldn't be that hard to write" necessarily has to exist. You may need to write it. Hey, you even have a road map ready:
Necessary Features:
Server can be configured and launched from javascript
Responses(including headers) can be configured on the fly
Responses can also be reset easily on the fly, without shutting down the server.
Now all you need is choose a name, create a repo on GitHub, create a project on npm and start coding.
You now, even "it wouldn't be that hard to write" it doesn't mean that it will write itself. Welcome to the open source world where instead of complaining that something doesn't exist people just write it.
You could try nock. https://github.com/node-nock
It supports all of your feature requests.
We have a somewhat big nodejs app using express. We started experimenting with hapijs on smaller services and kind of like it more than express. So we'd like to migrate the express app to hapijs. But since the app is already big, and we don't want to do a complete rewrite at once, but rewrite it step by step, so we can do it in more time. Is there any way to use express and hapijs within the same nodejs process and do the routing between those to by routes?
You should go through on this link:
Hecks
It will show you how to mount your express app onto your hapi server.
You have a couple of options to do it:
You can run those in two separate servers under a HAProxy and decide which server will answer by the route.
You can run 2 separate servers where Hapi will be in charge on all the routes once the route is not found it will proxy the request to express.
Option 1 will have better performance and help you in the future when you need to scale.
These days I try to develop real time application using nodejs.
That application want to update the dashboard according to api data.
I installed express and faye and try to compare what is the best and what are the differences of that two.
As I know express is a node base framework and faye is a subscriber/publisher based one.
But I think both are almost same and anyone can help me to identify the differences?
What is fast and what can be done using the frameworks like that ?
Thanks in advance.
They are not very comparable. If you want to create a real-time application, you will probably need to use both.
Express is a web framework. You will need it to serve and handle HTTP requests and responses. It will help you handle things like url routing, request/response handling middleware, interfacing with template engines, etc... Express is as fast as you'll get.
Faye is a pub sub messaging system- It will not be capable of handling standard HTTP requests and responses. You may be able to implement a live stream of the data using Faye, however, you will still have the need to serve up your client side application using Express.
I would also look into Socket.io as an alternative to Faye- in addition to Express.
Going to run Karma+Jasmine to test angularjs client with real backend. Since Karma is using its own express but I need to access real nodejs backend with DB and other stuff, I'm thinking on adding interceptor into $httpProvider.interceptors that will just replace my calls to /api and redirec them into real backend location. Is there a better way?
You don't want to do that on unit tests (and personally I wouldn't even do that with E2E tests).
When doing unit tests, the $httpBackend get swapped with a dummy version that is not capable of doing real requests. That is intentional. You shouldn't do any test with the real backend.
On the other hand, there are E2E tests (where you test all your system together) where you could use the real backend in your tests (there are people who likes that, people who doesn't).
Keep in mind that unit test are all about units in isolation, that means that you don't care about dependencies and much much less about a backend.