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

Cannot understand the difference in custom types #1042

Open
sharadregoti opened this issue Jan 21, 2021 · 2 comments · May be fixed by #1075
Open

Cannot understand the difference in custom types #1042

sharadregoti opened this issue Jan 21, 2021 · 2 comments · May be fixed by #1075
Labels
enhancement pkg-mock Any issues related to Mock

Comments

@sharadregoti
Copy link

I have a custom type of map called as collection which is map[string]Fields. You can check the image for detailed info.
When my test case failed, I am not able to understand the difference in the 4th argument clearly.

Types info
image

Test Case
image

@brackendawson
Copy link
Collaborator

brackendawson commented May 12, 2021

You have primed your mock with an initialised Collection, possibly using the literal syntax: Collection{}. But then you have called the mock with a nil Collection. The test output does show this: 4: main.Collection(nil) vs 4: main.Collection{}, however this part is less helpful: 4: FAIL: (main.Collection=map[]) != (main.Collection=map[]).

This will happen with non-custom slices and maps as well. This line is the source of the format:

expectedFmt = fmt.Sprintf("(%[1]T=%[1]v)", expected)

Perhaps it could be changed to use the go syntax here also by adding this #:

        expectedFmt = fmt.Sprintf("(%[1]T=%#[1]v)", expected)

For the OP

You need to prime the mock with a nil Collection, this is one way of doing that when your type is a map or a slice:

package main

import (
	"context"
	"testing"

	"github.com/stretchr/testify/mock"
)

type Collection map[string]int

type MockThing struct {
	mock.Mock
}

func (m *MockThing) SchemaInspection(ctx context.Context, alias, name, logs string, collection Collection) {
	m.Called(ctx, alias, name, logs, collection)
}

func TestCollection(t *testing.T) {
	thing := &MockThing{}
	thing.Test(t)

	// Incorrect
	thing.On("SchemaInspection",
		mock.Anything,
		"alias",
		"db_name",
		"invocation_logs",
		Collection{},
	).Return().Once()
	thing.SchemaInspection(context.Background(), "alias", "db_name", "invocation_logs", nil)

	// Correct
	thing.On("SchemaInspection",
		mock.Anything,
		"alias",
		"db_name",
		"invocation_logs",
		*new(Collection),
	).Return().Once()
	thing.SchemaInspection(context.Background(), "alias", "db_name", "invocation_logs", nil)
}

brackendawson pushed a commit to brackendawson/testify that referenced this issue May 12, 2021
When priming and calling a mock with an empty vs nil slice or map, the diff view showed two identical strings as being not equal. By using the go syntax it is always clear when one side is nil. The type is still needed to differentiate int64(7) from int32(7).

closes stretchr#1042
@brackendawson brackendawson linked a pull request May 12, 2021 that will close this issue
brackendawson added a commit to brackendawson/testify that referenced this issue May 12, 2021
When priming and calling a mock with an empty vs nil slice or map, the diff view showed two identical strings as being not equal. By using the go syntax it is always clear when one side is nil. The type is still needed to differentiate int64(7) from int32(7).

closes stretchr#1042
brackendawson added a commit to brackendawson/testify that referenced this issue May 12, 2021
When priming and calling a mock with an empty vs nil slice or map, the diff view showed two identical strings as being not equal. By using the go syntax it is always clear when one side is nil. The type is still needed to differentiate int64(7) from int32(7).

closes stretchr#1042
brackendawson added a commit to brackendawson/testify that referenced this issue May 12, 2021
When priming and calling a mock with an empty vs nil slice or map, the diff view showed two identical strings as being not equal. By using the go syntax it is always clear when one side is nil. The type is still needed to differentiate int64(7) from int32(7).

closes stretchr#1042
@dolmen dolmen added enhancement pkg-mock Any issues related to Mock question Questions related to API usage and removed question Questions related to API usage labels Jul 7, 2023
@dolmen
Copy link
Collaborator

dolmen commented Jul 7, 2023

@sharadregoti Do not post issues as screenshot. Copy-pasting code is not possible. In addition the contrast is very low on your snapshot and is hard to read for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement pkg-mock Any issues related to Mock
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants