Hi Demis,
What is your current setup/recommendations for unit testing where a Redis instance is involved?
The unit tests in ServiceStack.Redis seem to suggest that you’re running a local instance of a redis server (and a sentinel where pertinent) - I assume using Vagrant.
This would be fine for unit/integration testing on a local machine, but would pose a problem if the unit tests are aggregated and run when building through a CI process (TeamCity in my case).
I’ve taken a look at the RedisIntegration nuget package (which tries to create/kill a redis instance for unit testing - but I’m finding that the redis.exe process is not being reliably killed (and since the author of the package is using empty catch blocks in the package to throw away errors when killing the process I’m not convinced that this is the way to go).
I was wondering if you’ve experimented with automated integration testing of this nature, or if you have some advice/suggestions? Do you think it would be possible/advisable to try and start/stop a Vagrant-hosted instance for this type of automated integration testing?
I’m just running a local redis-server instance using vagrant (option 1: https://github.com/ServiceStack/redis-windows) but Windows redis service works as well. I just flushall before each test to nuke the data, so the unit tests themselves aren’t dealing with starting/killing redis process.
Carlos Mendes:
How about this? https://github.com/aspnet/Caching/blob/dev/test/Microsoft.Framework.Cache.Redis.Tests/Infrastructure/RedisTestConfig.cs
Ryan Britton:
+Demis Bellot: I thought as much - thanks.
+Carlos Mendes : a little bloated - but more or less what I thought I was going to end up doing, thanks. If I come up with something more elegant I’ll post it here…