A mock library that simulates a running Riak cluster (without actually having one)
Riak-mock is a Node.js module that mimics a real-life Riak server cluster that can be initialized, started, and stopped at will. Its goal is to provide developers with a reasonable approximation of the real thing to facilitate testing operations without having to depend on the availability of a real cluster.
var Riak = require'../index';var server = 8087;serverstart;
This will start a new server on port 8087 and attach it to all available IPs. The full signature of the server constructor is:
port hostname log;
stop([callback]) the server as needed. Every time a new server is created, it starts with a blank data store that you can populate as needed.
You can also run Riak-mock as a standalone server; this can be handy when you're trying to track down a particular issue and don't want to create a full environment to deal with the problem. You can do so by installing the module standalone in a location of your choice, and then running
npm start, which executes the
server.js file. The server includes a built-in logging facility that dumps to stdout.
- It should go without saying—but I'll say it anyway—that Riak-mock is not intended to be a replacement for Riak. Not only does it not support any of the features that make Riak great, like for clustering, load balancing, fault tolerance, and so on; it is also not optimized for standalone, single-server use at all. Its goal is simply to approximate a running instance of Riak to make writing unit tests easier.
- There are likely to be many subtle differences between the way Riak and Mock-Riak work. The long-term goal is to track those down and fix them, but caveat emptor.
- Riak-Mock doesn't support siblings.
- Map/Reduce phases in the form
- Overall, this project is very young; if your Riak usage goes beyond the basics, you're likely to encounter problems (in which case, bug reports—and, especially, patches—are welcome).
You are encouraged to submit patches for the bugs you find. However, you must also provide at least one unit test to cover the patch (unless, of course, the patch is either not code-related or is, itself, a unit test). I will not merge pull requests without covering unit tests, and it's a fair bet that I won't have the time to write the tests myself.
Also, if you want to help out, the project needs much better test coverage, especially when it comes to map/reduce operations, which are a little sketchy at the moment.