refactor(redlock): apply interface

[kiran94]

Context

Users of this library may want to mock RedLock when creating unit tests in their own application logic. I contemplated just creating the interface in my own project but I think it would be more useful for the community if the library just ships one itself. This should also provide a little more flexibily in the future as the underlying RedLock struct is abstracted away from users and you can switch out the implementation if ever needed.

Changes

• Introduce Public Interface RedLocker and swap out return for NewRedisLock
• Update TestNewRedisLock to verify underlying instance

[kiran94]

@vvanglro This one also

[vvanglro]

Can you give me a short example, I don't understand how the abstracted RedLocker is used when mocking RedLock or otherwise

[vvanglro]

I think I understand, I went to check the go interface, is it the following usage?

package main

import (
	"context"
	"fmt"
	"github.com/vvanglro/gredlock/redlock"
)

type mockRedLock struct {}

func (rl *mockRedLock) SetLock(ctx context.Context, key string, value string, ttl int) (float64, error) {
	return 1.1, nil
}

func (rl *mockRedLock) UnSetLock(ctx context.Context, key string, value string) (float64, error) {
	return 1.2, nil
}

func (rl *mockRedLock) GetLockTtl(ctx context.Context, key string, value string) (int64, error) {
	return 2, nil
}

func (rl *mockRedLock) IsLocked(ctx context.Context, key string) bool {
	return true
}

func main() {
	ctx := context.Background()
	key := "my-key"
	value := "my-value"
	ttl := 60
	var client redlock.RedLocker
	client = &mockRedLock{}
	resp, _ := client.SetLock(ctx, key, value, ttl)
	fmt.Println(resp)
	resp2, _ := client.GetLockTtl(ctx, key, value)
	fmt.Println(resp2)
	resp3 := client.IsLocked(ctx, key)
	fmt.Println(resp3)
	resp4, _ := client.UnSetLock(ctx, key, value)
	fmt.Println(resp4)
}

[kiran94]

I think I understand, I went to check the go interface, is it the following usage?

@vvanglro Yeah you basically got it

Users can now reference redlock.RedLocker in their own business logic instead.

Here is a real example:

1. Declare an Interface
2. Create a Mock (In this case using testify/mock but your approach is also valid)
3. Use the Mock

[vvanglro]

I'm thinking about a problem.

Can the return type of the method remain as is?

In this way, when I use it, I can directly click on the corresponding method and jump directly to the source code instead of an abstract interface. What do you think?

func NewRedisLock(ctx context.Context, options ...*red.Options) *RedLock {}

[kiran94]

@vvanglro It's obviously up to you 😄 but I would recommend keeping the abstraction as what your users are provided back

Most IDEs have a "Go to Implementation" Feature. I'm not sure what you are using but VSCode has this. If you right click on the method you should see it

[vvanglro]

Okay, I see. I'll keep it now. Thank you again.🙇‍♂️ I use goland.