MockPackage()

[Nate Finch]

John talked to me on a hangout and suggested that, often times, when you
need to expose something like this for tests, it ends up being something
that production code needs to tweak as well.  He'd like to see something
better than a public variable, but didn't offer a suggestion as to what.

I think this is a pretty good point, so I'll try to come up with a third
way that isn't too cumbersome.


On Mon, Mar 3, 2014 at 12:35 PM, Nate Finch <nate.finch at canonical.com>wrote:

> 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/4e36e7f1/attachment-0001.html>