FAQ
On closer inspection to my problem, having the individual interfaces isn't
that bad. The only thing bad about it is where they are used and stored,
and constructing that, struct.

So if you have:
type A struct {
   Field1 SomeInterface1
   Field2 SomeInterface2
   Field3 SomeInterface3
   Field4 SomeInterface4
   m map[string]int
   c chan struct{}
}

What do you provide as a constructor if you want to allow the four fields
to be pluggable for tests? Perhaps a New() that only creates the map and
chan and nil fields? Is that idiomatic?
Perhaps check if map and chan are created everywhere they are used and let
the default value of the struct be "usable", even if not really until they
plug a field?

On Thursday, April 16, 2015 at 6:16:07 PM UTC-7, jonathan...@gmail.com
wrote:
Hello gophers!

I am trying to find what is idiomatic or even a good way to structure a
large "context". So this application has an interface Machine that has its
implementation switched out on different machines. Problem I have is with
testing. If I just want to stub out a single method of that interface I
have to create a stub struct with a bunch of empty functions, it becomes
unwieldy in tests. I have heard of three approaches, mock lib, split the
interface, and have a struct with function values.

Mock lib approach I would rather avoid.

Splitting the interface has the issue that now I have to pass around all
the split interfaces which are roughly equal in number to the functions in
Machine.

Struct with function values is odd because I am still passing this whole
thing around whereas a portion of the application or my tests really only
need the one function. Perhaps small and not measured but I imagine it is
slower because of the extra indirection.

My intuition tells me I should be able to do it with better interface
design but I'm coming up with nothing :(
--
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

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 9 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 17, '15 at 1:15a
activeApr 17, '15 at 7:05p
posts9
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase