Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mocking Multiple Values Fails Randomly #73

Open
graytonio opened this issue May 30, 2023 · 2 comments
Open

Mocking Multiple Values Fails Randomly #73

graytonio opened this issue May 30, 2023 · 2 comments

Comments

@graytonio
Copy link

When mocking commands like XAdd with multiple values the test will fail randomly depending on the order of the values the mock and client decide to put them in. Is there a way to validate that these commands have the right values without caring about the order?

Example:

func DemoFunc(db *redis.Client) (string, error) {
    resp := db.XAdd(&redis.XAddArgs{
        Stream: "foo",
        ID: "*",
        Values: map[string]interface{}{
            "foo": "bar",
            "test": "baz",
        },
    })
}

func TestDemoFunc(t *testing.T) {
    db, mock := redismock.NewClientMock()

    mock.ExpectXAdd(&redis.XAddArgs{
        Stream: "foo",
        ID: "*",
        Values: map[string]interface{}{
            "foo": "bar",
            "test": "baz",
        },
    })

    got, err := DemoFunc(db)
    
    if err := mock.ExpectationsWereMet(); err != nil {
        t.Error(err)
    }
}

This code will randomly either pass or fail.

@squat
Copy link

squat commented Jul 31, 2024

I needed to figure this out today. For my use case it was sufficient to set mock.MatchExpectationsInOrder(false) as in the example: https://github.com/go-redis/redismock/blob/master/example/example.go#L72-L74

@benjfield
Copy link

I have this problem too - this is a problem for any unordered queries i.e coming from a map.

Unless I have it wrong, that flag only allows you to run the redis commands out of order, however in a single command with unsorted data (in my immediate case SINTER), it will not fix the problem.

I would appreciate any suggestions if anyone has one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants