Write unit tests against all (most of) redis versions

[kstyrc]

We should include in src/test/resources all (most of?) redis versions and create unit tests for each redis version: http://redis.io/download

TO CONSIDER: Which version should we package inside the published JAR in maven?

[hbenlulu]

Hi,

would it possible to add support for redis 2.8.* versions ?

[kstyrc]

Is there any problem with those? What kind?

[hbenlulu]

the current version of embedded-redis (0.3) does not support 2.8.* commands such as zscan

[kstyrc]

@hbenlulu You should be able to use your own executable for 2.8.* in the constructor of RedisServer. See the examples on the README page.

But if you mean that 2.8.* redis executable does not work, then I'll investigate, fix that and add unit tests for different releases of redis (2.6.x, 2.8.x, etc).

[hbenlulu]

At the moment I am using my own Redis executable for integration tests. However, the problem with this way is that no one else can run those tests unless Redis is pre-installed (and at the same location). For running CI with Jenkins, for example, I have to install Redis in all Jenkins slaves.

[kstyrc]

@hbenlulu How about adding this executable to /src/test/resources ? Then everybody has access to it & nothing has to be installed ;>

[hbenlulu]

This could be a great idea. However, I am using Mac while others are using Ubuntu and Windows.

I will look more closely into it and let you know

[kstyrc]

@hbenlulu That's pretty darn difficult. What embedded-redis does underneath is simply to run redis executable. By default, I'm providing support for: 1) Mac OS: some executable provided by one of contributors 2) Linux: official redis executable 3) Windows: branch 2.6 of some port https://github.com/MSOpenTech/redis

Keep in mind, that when using embedded-redis, you wanna do integration test with platform-specific software (redis db). So automatically you cannot provide these tests to be platform-independent, unfortunately ;<

By know, I would suggest you to find executables for all 3 platforms Mac/Linux/Windows for 2.8.* redis that work and pass them in constructor of RedisServer depending on OS, for help see: https://github.com/kstyrc/embedded-redis/blob/master/src/main/java/redis/embedded/RedisServer.java

I'll try to look into that and provide it in embedded-redis for different versions of redis.

[hbenlulu]

Thanks man.

[wenerme]

but, will you update the version? or put multi version in different maven like

 <dependency>
            <groupId>redis.embedded</groupId>
            <artifactId>embedded-redis-2.8</artifactId>
            <version>0.3</version>
            <scope>test</scope>
</dependency>

 <dependency>
            <groupId>redis.embedded</groupId>
            <artifactId>embedded-redis-2.6</artifactId>
            <version>0.3</version>
            <scope>test</scope>
</dependency>

This will be great! Let us choose the version.

[kstyrc]

Cool idea. But then the number of jars will go insanely up. Imagine embedded-redis-2.8.18 and then a new redis release comes out - 2.8.19. What should I do? Release a new version to maven repository? Packing up all different redis versions into one jar is also not suitable, as jar size will grow significantly.

Hmmm, how about enriching RedisServer constructor (builder too) a bit. You would need to provide a path to the redis executable like the following:

EnumMap<OSEnum, String> systemToExecutable = new EnumMap<>();
systemToExecutable.put(OSEnum.LINUX, "/path/to/your/linux/redis");
systemToExecutable.put(OSEnum.MACOS, "/path/to/your/macos/redis");
systemToExecutable.put(OSEnum.WINDOWS, "/path/to/your/windows/redis");

RedisServer redisServer = new RedisServer(systemToExecutable, 6379);
// or
RedisServer redisServer = RedisServer.builder()
  .executable(OSEnum.LINUX, "/path/to/your/linux/redis")
  .executable(OSEnum.MACOS, "/path/to/your/macos/redis")
  .executable(OSEnum.WINDOWS, "/path/to/your/windows/redis")
  .port(6379)
  .slaveOf("locahost", 6378)
  .configFile("/path/to/your/redis.conf")
  .build();

// will throw an Exception when you run on Windows, but no executable have been provided for Windows OS
redisServer.start();

@hbenlulu @wenerme How about that? Then you have the flexibility to provide any executable as you want, even the one you compiled with your own gcc options or with a patch you applied etc. But all the magic of detecting which OS you're running and choosing the appriopriate executable will be handled inside of the RedisServer, hmm?

[wenerme]

But we also have to maintain the executables. I can not copy to others and run, the environment is very hard to say.

How about only care the major version. 2.6, 2.8 which add new things.or use the maven version to reflect the minor version update.But for now, I just need HSCAN, so I need 2.8. and I don't care the minor version of redis.I think, in product, the redis server is not depend on the minor version.

[wenerme]

By the way , we also use mariadb in test. MariaDB4j this dependency is about 40MB, but we can just run it, that's what we want.

[ghillert]

I think the project should at least track the most recent major versions e.g. 2.8. I have created the following issue for that: https://github.com/kstyrc/embedded-redis/issues/23

Also, it looks like there may be the need/desire to support multiple Redis versions simultaneously. I see 2 use-cases:

Would it maybe make sense to externalize just the Redis binaries into their own Maven sub-module?

That way the main embedded-redis project does not have to provide Redis version-specific releases but rather references a transitive dependency containing the recent-Redis binaries.

However, if users prefer a different Redis binary version, they can just override the transitive dependency.

Add the ability to provide custom binary locations for all 3 major platforms

At present you can only specify a single custom binary to be used. As @kstyrc pointed out above - in testing scenarios or for samples, I may have to support all 3 major platforms simultaneously. It would be nice to provide all three binaries, similar to the example above.

[kstyrc]

@ghillert I've implemented it by adding the ability to provide custom binary locations for all 3 major platforms.

See https://github.com/kstyrc/embedded-redis/pull/29

Would be grateful for feedback