FAQ
I have an external dependency on a http client. I want to be able to test
the repository code that uses this dependency and so I have created an
interface in my repository that declares the methods used by the repository
and created a fake implementation along the lines described here

https://medium.com/@matryer/5-simple-tips-and-tricks-for-writing-unit-tests-in-golang-619653f90742#.ayj9w8tf7

The interface looks like this

type GetEventStoreRepositoryClient interface {
ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take) <-chan
struct {
*goes.EventResponse
*goes.Response
error
}

AppendToStream(string, *goes.StreamVersion, ...*goes.Event)
(*goes.Response, error)
}

However, when I try to run tests, I get the following error saying that the
client that I am trying to fake does not itself implement this interface.

./repository_test.go:41: cannot use store (type *goes.Client) as type
GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

*goes.Client does not implement GetEventStoreRepositoryClient (wrong type
for ReadStreamForwardAsync method)

have ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take) <-chan
struct { *goes.EventResponse; *goes.Response; error }

want ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take) <-chan
struct { *goes.EventResponse; *goes.Response; error }

As you can see, they appear identical.

Now if I declare the interface in the library rather than in the consuming
code, it works, but the interface belongs to the consuming code not the
library so I cant sensibly declare it there. It also works if I remove the
ReadStreamForwardAsync method and leave just the AppendToStream method.

I assume then that it is something to do with the channel return type.


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • GoNutter at May 10, 2016 at 12:08 pm
    Actually it doesnt quite work if I declare the interface in the library. If
    I declare the interface in the library then the fake in my consuming code
    does not implement the interface. If I declare the interface in the
    consuming code then the library client does not implement the interface.

    If I remove the method with the struct from the interface then all works
    from either side so it is surely something to do with the channel return
    type.
    On Tuesday, May 10, 2016 at 12:43:14 PM UTC+1, GoNutter wrote:

    I have an external dependency on a http client. I want to be able to test
    the repository code that uses this dependency and so I have created an
    interface in my repository that declares the methods used by the repository
    and created a fake implementation along the lines described here


    https://medium.com/@matryer/5-simple-tips-and-tricks-for-writing-unit-tests-in-golang-619653f90742#.ayj9w8tf7

    The interface looks like this

    type GetEventStoreRepositoryClient interface {
    ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take) <-chan
    struct {
    *goes.EventResponse
    *goes.Response
    error
    }

    AppendToStream(string, *goes.StreamVersion, ...*goes.Event)
    (*goes.Response, error)
    }

    However, when I try to run tests, I get the following error saying that
    the client that I am trying to fake does not itself implement this
    interface.

    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

    *goes.Client does not implement GetEventStoreRepositoryClient (wrong type
    for ReadStreamForwardAsync method)

    have ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { *goes.EventResponse; *goes.Response; error }

    want ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { *goes.EventResponse; *goes.Response; error }

    As you can see, they appear identical.

    Now if I declare the interface in the library rather than in the consuming
    code, it works, but the interface belongs to the consuming code not the
    library so I cant sensibly declare it there. It also works if I remove the
    ReadStreamForwardAsync method and leave just the AppendToStream method.

    I assume then that it is something to do with the channel return type.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at May 10, 2016 at 12:13 pm
    Are both the library and the client using the same goes dependency? If vendoring or GOPATH tricks are in play this may be an explanation.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 12:47 pm
    Hi Dave,

    goes is the name of the eventstore client that I am building. My cqrs code
    has the goes client as a dependency, I have not used vendoring to manage
    the dependency.

    https://github.com/jetbasrawi/goes

    Here is where I declare the interface in the cqrs library
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/fakes.go

    Line 41 here where I try to pass in an instance of the real client is where
    the exception is occurring
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/repository_test.go

    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

             *goes.Client does not implement GetEventStoreRepositoryClient (wrong
    type for ReadStreamForwardAsync method)

                     have ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { *goes.EventResponse; *goes.Response; error }

                     want ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { goes.EventResponse; goes.Response; error }

    You will see that a lot of the repository tests are commented out as I am
    in the the middle of a big refactoring making the repository work from the
    async method rather than the previous method, but have kinda ground to a
    halt here.


    On Tuesday, May 10, 2016 at 1:13:06 PM UTC+1, Dave Cheney wrote:

    Are both the library and the client using the same goes dependency? If
    vendoring or GOPATH tricks are in play this may be an explanation.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 12:50 pm
    It is a bit like it does not recognise a channel of struct in one side as
    the same as a channel of struct in the other side.

    Could this be a result of the anon structs being actually different types
    in each context, perhaps if I used a non anonymous struct it would work.
    will give that a try.
    On Tuesday, May 10, 2016 at 1:47:50 PM UTC+1, GoNutter wrote:

    Hi Dave,

    goes is the name of the eventstore client that I am building. My cqrs code
    has the goes client as a dependency, I have not used vendoring to manage
    the dependency.

    https://github.com/jetbasrawi/goes

    Here is where I declare the interface in the cqrs library
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/fakes.go

    Line 41 here where I try to pass in an instance of the real client is
    where the exception is occurring
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/repository_test.go

    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

    *goes.Client does not implement GetEventStoreRepositoryClient (wrong
    type for ReadStreamForwardAsync method)

    have ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { *goes.EventResponse; *goes.Response; error }

    want ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { goes.EventResponse; goes.Response; error }

    You will see that a lot of the repository tests are commented out as I am
    in the the middle of a big refactoring making the repository work from the
    async method rather than the previous method, but have kinda ground to a
    halt here.


    On Tuesday, May 10, 2016 at 1:13:06 PM UTC+1, Dave Cheney wrote:

    Are both the library and the client using the same goes dependency? If
    vendoring or GOPATH tricks are in play this may be an explanation.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jan Mercl at May 10, 2016 at 12:52 pm

    On Tue, May 10, 2016 at 2:47 PM GoNutter wrote:

    have ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { *goes.EventResponse; *goes.Response; error }
    want ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { goes.EventResponse; goes.Response; error }

    Note the difference between goes.X and *goes.X.

    --

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 1:01 pm
    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

             *goes.Client does not implement GetEventStoreRepositoryClient (wrong
    type for ReadStreamForwardAsync method)

                     have ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { *goes.EventResponse; *goes.Response; error }

                     want ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { *goes.EventResponse; *goes.Response; error }

    Hi Jan, thats not it. Sorry I had just been trying different forms of
    indirection to see if that had anything to do with it. If I put it back to
    how it was it gives the same error.

    I am beginning to hypothesize that under the hood, the compiler is doing
    something to facilitate anonymous types and it will create a name for it in
    one application that is actually different in the other...

    Going to try the same code with a non anonymous struct.
    On Tuesday, May 10, 2016 at 1:53:02 PM UTC+1, Jan Mercl wrote:


    On Tue, May 10, 2016 at 2:47 PM GoNutter <anewex...@gmail.com
    <javascript:>> wrote:
    have ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { *goes.EventResponse; *goes.Response; error }
    want ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { goes.EventResponse; goes.Response; error }

    Note the difference between goes.X and *goes.X.

    --

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jan Mercl at May 10, 2016 at 1:07 pm

    On Tue, May 10, 2016 at 3:02 PM GoNutter wrote:

    I am beginning to hypothesize that under the hood, the compiler is doing
    something to facilitate anonymous types and it will create a name for it in
    one application that is actually different in the other...


    Almost.

    """"
    Two struct types are identical if they have the same sequence of fields,
    and if corresponding fields have the same names, and identical types, and
    identical tags. Two anonymous fields are considered to have the same name.
    Lower-case field names from different packages are always different.
    """" [0]

    Note the last sentence above. It means that anonymous struct{error} defined
    in one package is a different type wrt to the "same" defined in a different
    package.

    To solve the issue, give that type a name.

       [0]: https://golang.org/ref/spec#Type_identity

    --

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 1:40 pm
    Hi Jan,

    I think you nailed it. However having changed the code to use a declared
    type I think the code is better for it in lots of ways. I think I will just
    go with the declared type.

    Many thanks for your help.
    On Tuesday, May 10, 2016 at 2:07:30 PM UTC+1, Jan Mercl wrote:




    On Tue, May 10, 2016 at 3:02 PM GoNutter <anewex...@gmail.com
    <javascript:>> wrote:
    I am beginning to hypothesize that under the hood, the compiler is doing
    something to facilitate anonymous types and it will create a name for it in
    one application that is actually different in the other...


    Almost.

    """"
    Two struct types are identical if they have the same sequence of fields,
    and if corresponding fields have the same names, and identical types, and
    identical tags. Two anonymous fields are considered to have the same name.
    Lower-case field names from different packages are always different.
    """" [0]

    Note the last sentence above. It means that anonymous struct{error}
    defined in one package is a different type wrt to the "same" defined in a
    different package.

    To solve the issue, give that type a name.

    [0]: https://golang.org/ref/spec#Type_identity

    --

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 1:43 pm
    @Egon, didnt you write a CQRS implementation? I am sure I saw one several
    weeks ago that was based on Greg's m-r code? Couldnt find it again since.
    On Tuesday, May 10, 2016 at 2:40:12 PM UTC+1, GoNutter wrote:

    Hi Jan,

    I think you nailed it. However having changed the code to use a declared
    type I think the code is better for it in lots of ways. I think I will just
    go with the declared type.

    Many thanks for your help.
    On Tuesday, May 10, 2016 at 2:07:30 PM UTC+1, Jan Mercl wrote:



    On Tue, May 10, 2016 at 3:02 PM GoNutter wrote:

    I am beginning to hypothesize that under the hood, the compiler is
    doing something to facilitate anonymous types and it will create a name for
    it in one application that is actually different in the other...


    Almost.

    """"
    Two struct types are identical if they have the same sequence of fields,
    and if corresponding fields have the same names, and identical types, and
    identical tags. Two anonymous fields are considered to have the same name.
    Lower-case field names from different packages are always different.
    """" [0]

    Note the last sentence above. It means that anonymous struct{error}
    defined in one package is a different type wrt to the "same" defined in a
    different package.

    To solve the issue, give that type a name.

    [0]: https://golang.org/ref/spec#Type_identity

    --

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at May 10, 2016 at 2:12 pm

    On Tuesday, 10 May 2016 16:42:58 UTC+3, GoNutter wrote:
    @Egon, didnt you write a CQRS implementation? I am sure I saw one several
    weeks ago that was based on Greg's m-r code? Couldnt find it again since.
    Well, yes and no... it was an actual piece from an application... I
    uploaded it because of a discussion and thoughtlessly named it "cqrs/es
    library".

    I adjusted and clarified the README
    (https://github.com/egonelbre/guestlist) ... I probably would implement
    some things differently now.

    + Egon

    On Tuesday, May 10, 2016 at 2:40:12 PM UTC+1, GoNutter wrote:

    Hi Jan,

    I think you nailed it. However having changed the code to use a declared
    type I think the code is better for it in lots of ways. I think I will just
    go with the declared type.

    Many thanks for your help.
    On Tuesday, May 10, 2016 at 2:07:30 PM UTC+1, Jan Mercl wrote:



    On Tue, May 10, 2016 at 3:02 PM GoNutter wrote:

    I am beginning to hypothesize that under the hood, the compiler is
    doing something to facilitate anonymous types and it will create a name for
    it in one application that is actually different in the other...


    Almost.

    """"
    Two struct types are identical if they have the same sequence of fields,
    and if corresponding fields have the same names, and identical types, and
    identical tags. Two anonymous fields are considered to have the same name.
    Lower-case field names from different packages are always different.
    """" [0]

    Note the last sentence above. It means that anonymous struct{error}
    defined in one package is a different type wrt to the "same" defined in a
    different package.

    To solve the issue, give that type a name.

    [0]: https://golang.org/ref/spec#Type_identity

    --

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 2:25 pm
    Ah yes thats the one. It was from the discussion which was around
    eventhorizon that I read.
    On Tuesday, May 10, 2016 at 3:12:52 PM UTC+1, Egon wrote:
    On Tuesday, 10 May 2016 16:42:58 UTC+3, GoNutter wrote:

    @Egon, didnt you write a CQRS implementation? I am sure I saw one several
    weeks ago that was based on Greg's m-r code? Couldnt find it again since.
    Well, yes and no... it was an actual piece from an application... I
    uploaded it because of a discussion and thoughtlessly named it "cqrs/es
    library".

    I adjusted and clarified the README (
    https://github.com/egonelbre/guestlist) ... I probably would implement
    some things differently now.

    + Egon

    On Tuesday, May 10, 2016 at 2:40:12 PM UTC+1, GoNutter wrote:

    Hi Jan,

    I think you nailed it. However having changed the code to use a declared
    type I think the code is better for it in lots of ways. I think I will just
    go with the declared type.

    Many thanks for your help.
    On Tuesday, May 10, 2016 at 2:07:30 PM UTC+1, Jan Mercl wrote:



    On Tue, May 10, 2016 at 3:02 PM GoNutter wrote:

    I am beginning to hypothesize that under the hood, the compiler is
    doing something to facilitate anonymous types and it will create a name for
    it in one application that is actually different in the other...


    Almost.

    """"
    Two struct types are identical if they have the same sequence of
    fields, and if corresponding fields have the same names, and identical
    types, and identical tags. Two anonymous fields are considered to have the
    same name. Lower-case field names from different packages are always
    different.
    """" [0]

    Note the last sentence above. It means that anonymous struct{error}
    defined in one package is a different type wrt to the "same" defined in a
    different package.

    To solve the issue, give that type a name.

    [0]: https://golang.org/ref/spec#Type_identity

    --

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at May 10, 2016 at 1:28 pm

    On Tuesday, 10 May 2016 15:47:50 UTC+3, GoNutter wrote:
    Hi Dave,

    goes is the name of the eventstore client that I am building. My cqrs code
    has the goes client as a dependency, I have not used vendoring to manage
    the dependency.
    Watch this https://youtu.be/LDW0QWie21s at 32min mark (or the whole thing).

    *tl;dr; don't write a CQRS or Event Sourcing framework.*

    https://github.com/jetbasrawi/goes
    Here is where I declare the interface in the cqrs library
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/fakes.go
    <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjetbasrawi%2Fyoono-cqrs%2Fblob%2Fmaster%2Ffakes.go&sa=D&sntz=1&usg=AFQjCNH73M_H8PZVyEz0AKSHAc7_OEZCIw>

    Line 41 here where I try to pass in an instance of the real client is
    where the exception is occurring
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/repository_test.go

    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

    *goes.Client does not implement GetEventStoreRepositoryClient (wrong
    type for ReadStreamForwardAsync method)

    have ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { *goes.EventResponse; *goes.Response; error }

    want ReadStreamForwardAsync(string, *goes.StreamVersion, *
    goes.Take) <-chan struct { goes.EventResponse; goes.Response; error }

    You will see that a lot of the repository tests are commented out as I am
    in the the middle of a big refactoring making the repository work from the
    async method rather than the previous method, but have kinda ground to a
    halt here.


    On Tuesday, May 10, 2016 at 1:13:06 PM UTC+1, Dave Cheney wrote:

    Are both the library and the client using the same goes dependency? If
    vendoring or GOPATH tricks are in play this may be an explanation.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 1:37 pm
    Don't worry Egon, I am not writing a CQRS framework, I am well aware of
    Greg Young's advice in this respect. I am however writing a CQRS
    implementation for use in my project.
    On Tuesday, May 10, 2016 at 2:28:11 PM UTC+1, Egon wrote:


    On Tuesday, 10 May 2016 15:47:50 UTC+3, GoNutter wrote:

    Hi Dave,

    goes is the name of the eventstore client that I am building. My cqrs
    code has the goes client as a dependency, I have not used vendoring to
    manage the dependency.
    Watch this https://youtu.be/LDW0QWie21s at 32min mark (or the whole
    thing).

    *tl;dr; don't write a CQRS or Event Sourcing framework.*

    https://github.com/jetbasrawi/goes
    Here is where I declare the interface in the cqrs library
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/fakes.go
    <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjetbasrawi%2Fyoono-cqrs%2Fblob%2Fmaster%2Ffakes.go&sa=D&sntz=1&usg=AFQjCNH73M_H8PZVyEz0AKSHAc7_OEZCIw>

    Line 41 here where I try to pass in an instance of the real client is
    where the exception is occurring
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/repository_test.go

    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

    *goes.Client does not implement GetEventStoreRepositoryClient (wrong
    type for ReadStreamForwardAsync method)

    have ReadStreamForwardAsync(string, *goes.StreamVersion,
    *goes.Take) <-chan struct { *goes.EventResponse; *goes.Response; error }

    want ReadStreamForwardAsync(string, *goes.StreamVersion,
    *goes.Take) <-chan struct { goes.EventResponse; goes.Response; error }

    You will see that a lot of the repository tests are commented out as I am
    in the the middle of a big refactoring making the repository work from the
    async method rather than the previous method, but have kinda ground to a
    halt here.


    On Tuesday, May 10, 2016 at 1:13:06 PM UTC+1, Dave Cheney wrote:

    Are both the library and the client using the same goes dependency? If
    vendoring or GOPATH tricks are in play this may be an explanation.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at May 10, 2016 at 1:44 pm

    On Tuesday, 10 May 2016 16:37:35 UTC+3, GoNutter wrote:
    Don't worry Egon, I am not writing a CQRS framework, I am well aware of
    Greg Young's advice in this respect. I am however writing a CQRS
    implementation for use in my project.
    Good just verifying... just in case ;)

    On Tuesday, May 10, 2016 at 2:28:11 PM UTC+1, Egon wrote:


    On Tuesday, 10 May 2016 15:47:50 UTC+3, GoNutter wrote:

    Hi Dave,

    goes is the name of the eventstore client that I am building. My cqrs
    code has the goes client as a dependency, I have not used vendoring to
    manage the dependency.
    Watch this https://youtu.be/LDW0QWie21s at 32min mark (or the whole
    thing).

    *tl;dr; don't write a CQRS or Event Sourcing framework.*

    https://github.com/jetbasrawi/goes
    Here is where I declare the interface in the cqrs library
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/fakes.go
    <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjetbasrawi%2Fyoono-cqrs%2Fblob%2Fmaster%2Ffakes.go&sa=D&sntz=1&usg=AFQjCNH73M_H8PZVyEz0AKSHAc7_OEZCIw>

    Line 41 here where I try to pass in an instance of the real client is
    where the exception is occurring
    https://github.com/jetbasrawi/yoono-cqrs/blob/master/repository_test.go

    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

    *goes.Client does not implement GetEventStoreRepositoryClient (wrong
    type for ReadStreamForwardAsync method)

    have ReadStreamForwardAsync(string, *goes.StreamVersion,
    *goes.Take) <-chan struct { *goes.EventResponse; *goes.Response; error }

    want ReadStreamForwardAsync(string, *goes.StreamVersion,
    *goes.Take) <-chan struct { goes.EventResponse; goes.Response; error }

    You will see that a lot of the repository tests are commented out as I
    am in the the middle of a big refactoring making the repository work from
    the async method rather than the previous method, but have kinda ground to
    a halt here.


    On Tuesday, May 10, 2016 at 1:13:06 PM UTC+1, Dave Cheney wrote:

    Are both the library and the client using the same goes dependency? If
    vendoring or GOPATH tricks are in play this may be an explanation.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • GoNutter at May 10, 2016 at 1:35 pm
    Yep, the issue appears to be passing the anonymous struct between the
    packages. If I replace the anonymous struct with a declared struct it works
    fine.

    type GetEventStoreRepositoryClient interface {
    ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take) <-chan
    *goes.AsyncResponse
    AppendToStream(string, *goes.StreamVersion, ...*goes.Event)
    (*goes.Response, error)
    }

    many thanks to all for jumping in and helping. I guess with hindsight this
    makes complete sense. Under the hood the compiler must be assigning some
    package specific type to the anonymous struct that will be different in the
    other package but not made explicit as this would defeat the whole purpose
    of anonymous structs.
    On Tuesday, May 10, 2016 at 12:43:14 PM UTC+1, GoNutter wrote:

    I have an external dependency on a http client. I want to be able to test
    the repository code that uses this dependency and so I have created an
    interface in my repository that declares the methods used by the repository
    and created a fake implementation along the lines described here


    https://medium.com/@matryer/5-simple-tips-and-tricks-for-writing-unit-tests-in-golang-619653f90742#.ayj9w8tf7

    The interface looks like this

    type GetEventStoreRepositoryClient interface {
    ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take) <-chan
    struct {
    *goes.EventResponse
    *goes.Response
    error
    }

    AppendToStream(string, *goes.StreamVersion, ...*goes.Event)
    (*goes.Response, error)
    }

    However, when I try to run tests, I get the following error saying that
    the client that I am trying to fake does not itself implement this
    interface.

    ./repository_test.go:41: cannot use store (type *goes.Client) as type
    GetEventStoreRepositoryClient in argument to NewCommonDomainRepository:

    *goes.Client does not implement GetEventStoreRepositoryClient (wrong type
    for ReadStreamForwardAsync method)

    have ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { *goes.EventResponse; *goes.Response; error }

    want ReadStreamForwardAsync(string, *goes.StreamVersion, *goes.Take)
    <-chan struct { *goes.EventResponse; *goes.Response; error }

    As you can see, they appear identical.

    Now if I declare the interface in the library rather than in the consuming
    code, it works, but the interface belongs to the consuming code not the
    library so I cant sensibly declare it there. It also works if I remove the
    ReadStreamForwardAsync method and leave just the AppendToStream method.

    I assume then that it is something to do with the channel return type.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 10, '16 at 11:43a
activeMay 10, '16 at 2:25p
posts16
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase