On Fri, Feb 13, 2015 at 2:05 PM, Eric Snow <eric.s...@canonical.com> wrote: > As for me, by "fake" I mean a struct that implements an interface with > essentially no logic other than to keep track of method calls and > facilitate controlling their return values explicitly. For examples > see the implementations for GCE and in `testing/fake.go`. Thus in > tests a fake may be used in place of the concrete implementation of > the interface that would be used in production.
To me this is a good fake implementation: https://github.com/juju/juju/tree/master/provider/dummy > The onus is on the test writer to populate the fake with the correct > return values such that they would match the expected behavior of the > concrete implementation. That's an optimistic view of it, as I described. > Regardless, I'm convinced that testing needs to include both high > coverage via isolated unit tests and good enough coverage via "full > stack" integration tests. Essentially we have to ensure that layers > work together properly and that low-level APIs work the way we expect > (and don't change unexpectedly). That's globally agreed. What's at stake is how to do these. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
