MockPackage()

[Nate Finch]

In some places, we have exposed constants that should not normally be
public as public variables, purely for the purpose of testing.  The reason
we need to do that, is because packages can't use code that is only exposed
in _test files for other packages (i.e.  package foo has a export_test.go
that it uses to export wrappers for internal things to be tweaked during
testing.  However, package bar can't access the stuff in foo's
export_test.go, only foo can access that stuff.)

The problem with these public variables is that the only thing preventing
people from using them is a comment that says "this is only for testing,
don't modify during production".

If you're consuming the code and see this public name pop up in code
completion, you might not realize it's only for testing, and use it anyway.

I've actually seen and fixed a bug like this, where production code was
twiddling with one of these variables that it was not supposed to be using.

The fix I thought up was to instead make a function called MockPackage().
 This function does everything that is needed to mock out the package for
testing, and returns a function that undoes the mocking.

The reason I like this better that public variables is twofold:

1.) It's a lot more obvious that MockPackage is something that you
shouldn't be calling in production code... rather than some vaguely named
public variable that may or may not be one of these special "do not touch"
variables.  This is doubly true if MockPackage becomes a standard pattern.

2.) It abstracts away the mocking of this package from consumers of the
package, so that if the package changes and needs to modify how it mocks
out its functionality, you don't have to change any other code.

I used this pattern in a merge proposal, and Roger suggested we just do it
the old way, with a public variable... so I'd like more input from the team.

-Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140303/7d101e67/attachment.html>