I would name your interface 'customer', the struct in the main code
'customerImpl' and the struct in the test code 'mockedCustomer'. However,
we are dealing with unexported types here. I tend to be less picky about
names for unexported types and prefer to leave them to each programmer's
discretion as long as the names are reasonable.
In general, I adopt the following guidelines:
For an exported interface that does not represent any domain idea and they
are there because of their methods, I would adopt the "-er" naming
convention. (eg. Stringer, Closer, etc.)
For an exported interface that represents a domain idea, I would use the
domain object name. It is preferable to have a noun with no adjective (eg.
Customer, Product, Shop, etc.)
For a struct that is not exported but it is the concrete implementation
of an exported interface, I would use the "<interface_name>+Impl"
or "<adjective><interface_name>+Impl" to indicate that the struct is the
concrete implementation of a public interface (eg. customerImpl,
specialCustomerImpl, customShopImpl, etc.) .
For a struct that is exported, I would use the "<adjective><noun>" format.
(eg. PublicAccountant, etc.).
For any interface or struct that is used for testing purposes only, I
would prefix the name with the word "mocked".
For any interface or struct that is not exported, I would leave them to the
programmer's discretion.
That's what I would do. You may adopt a different naming convention. As far
as I know, Go puts very little restriction on the subject.
On Sunday, March 5, 2017 at 10:04:47 AM UTC+7, mlg wrote:
> Nope, that's not it :'(. Here's a better way to explain:
>
> main.go
> // (unexported)
> type database?? interface { // how do I name this?
> query() (result, error)
> }
>
> // (unexported)
> type database?? struct {} // how do I name this?
>
> func (d database??) query() (result, error) {
> ...
> }
>
> test.go
> // (unexported)
> type mockDatabase struct {} // this name makes sense to me
>
> func (d database??) query() (result, error) {
> ...
> }
>
> If I've known it was gonna be this hard to get my point across, I would
> have done this from the start; I'm terribly sorry for wasting so much of
> your time.
>
> On Sunday, 5 March 2017 15:30:17 UTC+13, Henry wrote:
>>
>> Let's see if I understand your question correctly. You have the interface
>> in your main code, and the implementing struct in your test code. Do I get
>> that right?
>>
>> Another question is whether the main code and the test code live in the
>> same package or different package. I normally put my test code in a
>> separate package. So if my main code is in package abc, then my test code
>> would be in abc_test.
>>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
