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 <[email protected]> wrote: > On 31 October 2013 05:21, Andrew Wilkins <[email protected]> > 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
