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.

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.