Running the server in process is necessary for the mock to work. This is an approach I’ve taken in the past. I experimented with this setup quite a bit when I was playing around with a test suite, and it seemed to work well enough. Setting `process.argv` is a admitedly a bit gross, though a cleaner approach would require more involved changes to `server.js`.
Given the chunks coming from imagemagick are getting stored memory and
then tucked into a cache, this function could as easily return a buffer
via callback. Streaming is just making it more complex. (And trickier to
test!)
In ef1a5159, the switch to using imagemagick made a faulty use of the library by
listening for an 'end' event that is never raised. As a result, the cache was
never populated.
In d985f81f, a fix that takes care of the fact that the previously mentioned
dead code relies on a non-existent variable caused it to kill the server when a
raster badge is requested twice, as what it stored in the cache was the pipe
transmitting chunks, not the chunks themselves, and the pipe (a Socket object)
cannot be subsequently sent through a pipe. The following error occured instead:
events.js:163
throw er; // Unhandled 'error' event
^
TypeError: Invalid non-string/buffer chunk
at chunkInvalid (_stream_readable.js:395:10)
at readableAddChunk (_stream_readable.js:150:12)
at DataStream.Readable.push (_stream_readable.js:136:10)
at DataStream._read (/home/m/shields/lib/svg-to-img.js:45:21)
at DataStream.Readable.read (_stream_readable.js:350:10)
at resume_ (_stream_readable.js:739:12)
at _combinedTickCallback (internal/process/next_tick.js:80:11)
at process._tickDomainCallback (internal/process/next_tick.js:128:9)
The following warning is emitted by Node.js:
> DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new
> Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or
> `Buffer.alloc()` instead.
This patch removes this warning.
