State interfaces

[Nate Finch]

Defining small interfaces is the best way to make your code testable
without making it unwieldy.  The nice thing about Go interfaces is that you
don't have to make an interface that covers all your bases, since there's
very little friction to creating interfaces for your specific use case.
 Often the hardest thing is just figuring out a reasonable name.

I find that by trying to make most of my functions small and testable, they
become a lot more simple and easier to reason about.  Sometimes it requires
some minor changes to the upstream code, but often times that makes the
upstream code more readable too.  For example, instead of reading a config
file, parsing it, and then acting on it, I might read the file in one
function, parse it in another, and act on it in another.  It makes the code
so much easier to maintain if you don't have all that glommed together in a
single function, and a lot easier to test when you don't have to make a
fake test file to parse, and instead can just pass an io.Reader to your
parse method.



On Thu, Oct 31, 2013 at 9:24 AM, roger peppe <rogpeppe at gmail.com> wrote:

> On 31 October 2013 05:21, Andrew Wilkins <andrew.wilkins at canonical.com>
> wrote:
> > Does anybody object to converting the public entity structs in state to
> > interfaces? i.e. State, Machine, Unit, etc.
> >
> > I'd like to write some tests for new code that depends on state. Setting
> up
> > mongo and so on is overkill. and should be relegated to integration
> testing.
>
> If State was an interface, it alone would have 45 methods, not
> counting 190 more in Machine, Unit, etc; this seems really quite unwieldy.
> It certainly wouldn't be easy to implement a mock implementation without
> using
> the original.
>
> Without knowing more about your particular problem I can't say
> much more, but John's suggestion seems sound and is one I've
> been using recently (see worker/addressupdater for example) -
> inventing ad hoc interfaces that describe the local needs of the importer,
> rather than providing giant interfaces that try to be all things to
> all users.
>
>    cheers,
>     rog.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131031/d7e1bd08/attachment.html>