For TDD and BDD is would be awesome to have a mocking library like what nock does for http requests. I found one for node-amqp but, obviously, I'd prefer to use amqplib.
I have to admit I don't know much about mocking, and I'm not sure how it's used in practice. Do you have an example of how you use mocking with node-amqp?
@squaremo example mocking library for node-amqp — https://github.com/rstuven/node-amqp-mock
Thanks @dolphin278. I'm a bit unsure about the purpose of such a library -- is it for testing that your application code calls the right methods on a faked AMQP connection? Is that something that needs to be done specifically per-library; or could you use a toolkit to construct it?
The example posted above and its stated inspiration nock strike me as an odd way to go about things. If your application uses HTTP directly, then wouldn't you mock (i..e, supply a replacement for) the HTTP client; and if it uses e.g., the CouchDB client, wouldn't you mock that client. It seems pretty fragile to me, to test one's use of e.g., a CouchDB client by meddling with the HTTP library.
tl;dr If you can think of a good way to mock calls to your amqp client without having to mess with the HTTP library, that's perfect.
Regarding the purpose:
A true unit test will only test a specific block of code independent of any external system. Once you introduce an external server, like an amqp server, then you're actually performing a integration test or possibly even a system test.
So in order to test only the code you want tested, then we need to mock results returning from the server. So mocking the client works just fine but to "supply a replacement for" is not the typical strategy in a dynamically typed language. When you use something like sinon, it is effectively monkey patching.
Nock meddles with the HTTP library because, in many cases, that is the client.
@squaremo Just mentioned it here since you asked for an example. Personally, if I decided to go for mocks, I would slap something together using general purpose mocking library like http://sinonjs.org/ or even just straightforward fake objects.
@djensen47 OK, so I'm on the right page more or less. The connection class is handed a Stream, so that would be one natural place to swap in a fake server socket -- in fact I do something very like that in many of the tests. I stopped short of doing it for the API tests, since it would need a fairly detailed (and probably rather brittle) model of what a broker does. Those tests end up being something like integration tests, as you say.
@dolphin278 Yep I was leaning towards fake objects i.e., no monkey-patching.