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.

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.