Sandbox test setup for redis

If I had a logic that requires a real redis instance to test (e. g. pubsub subscription, polling from the other place, or like,) I’d definitely supply a PR to redix implementing the testing framework.

I never had such a condition (e. g. I used redis as a pure kv-store,) and since I trust in Andrea’s coding skills, I mock it completely.

That is true, this is my use-case too. I am not very familiar with redis, this is why I would like the calls to go to a real instance, just in case some of my assumptions when it comes to mocking are wrong, I would rather spend my time on a better testing setup than debugging that on deployed thing.

What an original approach!

Well, then you might want to open the issue to:

• declare Redix.Behaviour
• make Redix implement it
• create Redix.Test implementing this same behaviour and mimicking Redix by optionally wrapping each and every call to transaction_pipeline/3 and telemetrying it

Since redis doesn’t have a rollback mechanism at all, you’ll need to WATCH the data and/or implement the rollback manually. Here is a good blog about why You Don’t Need Transaction Rollbacks in Redis.

You anyway would need to implement all the above, hence my proposal to do a PR.

I won’t have time to do this now, as I will need some time to understand how test setups work and how to do the rollbacks correctly (so it would work with async tests too), but I would be most certainly interested in adding the feature as soon as I get a little bit more time as there is a lot of redis usage at the current projects I work on.

I wonder if it makes sense to make the implementation more abstract, as I will be most probably be interested in doing this with MongoDB tests too and I bet there is no way to do that ATM.

Should not we summon @whatyouhide here?

I am thinking about something that would make it possible to write tests like

test "redix_interop" do
  assert_redix_set "foo", 42, fn -> send(MyProcess, {:foo, 42}) end
  assert_redix_change, "bar", 3, fn -> MyModule.update_bars(& &1 + 3) end
  assert_redix ...
end

The approach I took to testing an application that used Redis was to start multiple Redis instances.

I used an Agent to pass out unused ports to tests, and would start a Redis server listening on that unused port using System.cmd/3, then pass the port in the ExUnit context, which would find its way into the app configuration. That way, each test that required Redis could have its own unique instance, which meant tests could be run concurrently.

While this isn’t very efficient, it works well enough during local development and in CI that it isn’t enough of an issue to replace at the moment.

Here’s the module I wrote for starting Redis instances:

defmodule Banker.Helper.RedisPortAgent do
  @moduledoc false
  use Agent

  @spec start_link() :: Agent.on_start()
  def start_link do
    opts = [name: __MODULE__]
    Agent.start_link(fn -> 20_000 end, opts)
  end

  @spec unique_redis() :: {:ok, map()}
  def unique_redis do
    port = Agent.get_and_update(__MODULE__, fn port -> {port, port + 1} end)

    wrapper = Path.join([:code.priv_dir(:banker), "port_wrapper.sh"])
    redis_server = System.find_executable("redis-server") || raise "redis-server not found"

    redis =
      Port.open(
        {:spawn_executable, wrapper},
        args: [
          redis_server,
          "--port",
          to_string(port),
          "--save",
          ~S("")
        ]
      )

    {:ok, %{port: port, redis: redis}}
  end
end

and port_wrapper.sh:

#!/usr/bin/env bash

# Start the program in the background
exec "$@" &
pid1=$!

# Silence warnings from here on
exec >/dev/null 2>&1

# Read from stdin in the background and
# kill running program when stdin closes
exec 0<&0 $(
  while read; do :; done
  kill -KILL $pid1
) &
pid2=$!

# Clean up
wait $pid1
ret=$?
kill -KILL $pid2
exit $ret

You don’t necessarily need multiple Redis instances. Every instance has 16 “databases” by default, addressable from 0 through 15. The data in each of those databases is completely isolated, and you’re actually able to selectively flush a single db.

You can use separate database instances for each test case (anything that is testing for the presence of specific values) and then call flushdb afterwards to clear only that database.

I don’t think Redix itself should change to accommodate testing here. Redix is concerned with talking to the Redis database, and it gives you enough tools that you can build testing utilities on top of it. The databases examples that @sorentwo mentioned is already a really good way to go with at least 16 parallel tests using Redis. Multiple instances also work—Redis is really cheap to run.

Redis itself doesn’t support complex transactions the way relational DBs (Postgres and co) that Ecto supports do, so implementing a sandbox here would not really be possible.

In case mocks are your choice, I don’t think Redix should declare and/or implement behaviours for that either. Redix’s API is pretty slim and chances are you’re not using all of it, so declaring the interface you need to talk to Redis for your use case and then declaring mocks for that seems like a good approach to me.