HAhackula1·Oct 21, 2013
A couple suggestions:
callback hell -- 1) Define your callback functions instead of passing anonymous functions everywhere. 2) Use a control flow library like async. https://npmjs.org/package/async This will greatly help in complex scenarios and the "waterfall" mode is particularly useful to accomplish something similar to chaining where values flow through multiple functions. Callback hell is not really an issue for most people after looking into these two things.
data manipulation -- https://npmjs.org/package/lodash lodash is a fast functional utility library that makes it much easier to do the everyday data manipulation tasks. I pretty much assume this will be a dependency whenever I start a non-trivial project now.
lack of standards -- Most people who really like node.js see this as a feature not a bug. This definitely drives away ma
Read the rest
ny people, but the intention is to promote as much choice as possible. Node.js people tend to be obsessed with choice and modularity. This is not meant as "you should think this way too" type explanation, but just a rough description of how the community is, good or bad. That being said, there are some standards out there. For example Felix's style guide is followed pretty well throughout the community (with a couple notable exceptions such as some of TJ Holowaychuk's stuff) http://nodeguide.com/style.html.
mocha output -- It appears you have your reporter option set to "spec". This is a great reporter for visualizing a set of features, but for integration with something like Jenkins, I would recommend "tap" instead. It is also pretty trivial to write your own reporter, and then you can get whatever type of output you want. https://github.com/visionmedia/mocha/wiki/Third-party-report...
mocha integration testing -- I agree that the example you showed was more of an integration test than a unit test. Mocha is not really doing anything to discourage unit testing though, and I would note that integration tests can be valuable. If it were me, I would tend to have my unit tests working against the actual module, instead of an endpoint, which is kind of sloppy.
I hope that helps though :) I know it is often frustrating coming into a new language ecosystem, especially a "friendly-anarchy" oriented one like node.js.