EXPECT fails when using type derived from map

[jtyers]

If I derive a type from a core type and use that in my expectations, tests start failing where they didn't before, even where the inputs have not changed. I've only tested this with a map.

Below is a complete working test that shows a given input working when I pass a map to the EXPECT (and mock), and then when I pass an M{}. The inputs stay the same, but the second test fails.

package main

//go:generate mockgen -source=$GOFILE -destination=test_mock.go -package main

import (
    "github.com/golang/mock/gomock"
    "testing"
)

type M map[string]interface{}

type TestInterface interface {
    DoSomething(input map[string]interface{})
}

func TestDoSomething(t *testing.T) {

    t.Run("using maps", func(t *testing.T) {
        ctrl := gomock.NewController(t)
        defer ctrl.Finish()

        mock := NewMockTestInterface(ctrl)

        mock.EXPECT().DoSomething(map[string]interface{}{"foo": "bar"})

        mock.DoSomething(map[string]interface{}{"foo": "bar"})

    })

    t.Run("using M", func(t *testing.T) {
        ctrl := gomock.NewController(t)
        defer ctrl.Finish()

        mock := NewMockTestInterface(ctrl)

        mock.EXPECT().DoSomething(M{"foo": "bar"})

        mock.DoSomething(M{"foo": "bar"})

    })
}

Additional Information Golang 1.14.1

[codyoss]

@jtyers Can you please share the versions were this both did and did not work(mockgen)?

[jtyers]

@codyoss sorry, here it is:

go: found github.com/golang/mock/mockgen in github.com/golang/mock v1.4.3
go: downloading golang.org/x/tools v0.0.0-20190425150028-36563e24a262

[jtyers]

To be clear I'm not aware of this ever working in mockgen. My reference to "tests failing where they didn't before" is that in the old version of my code, I used map[string]interface{} and in the new version, M.

[jtyers]

Also of interest may be that if I change the signature to DoSomething(input M) the test stlil fails.

[codyoss]

Thank you for all the information that helps! Yes is seems like our type checking might be too strict. My guess with out looking at the code is we need to add some reflect checks around if the type is assignable. I would be glad to accept a PR for such a feature 😸