Need team agreement on testing imports

Ian Booth ian.booth at canonical.com
Fri Jun 28 02:06:39 UTC 2013


Huge +1000 to local import.
Readability is much better that way and looks more natural.

If we use local imports for gocheck, WTF not for our own checkers? It seems
madness that some checkers are "special" and other aren't. Surely from a
consistency perspective, we'd stick with one paradigm or the other. Inconsistent
code causes confusion and is harder to parse. Code is written once but read many
times.

If we are forced to import checkers "normally", then we should do the same for
gocheck also.

On 28/06/13 10:44, Tim Penhey wrote:
> Hi All,
> 
> We currently have two commonly used idioms for importing checkers.  In
> particular "launchpad.net/juju-core/testing/checkers".
> 
> I have the preference of importing the checkers into the local namespace
> so they behave in the same way as the gocheck checkers.  I find this
> makes the tests more readable.  Given that the checkers package should
> only be bringing in checkers and not miscellaneous functions, then I'm
> happy to bring them into the local namespace.
> 
> This means we have:
> 
>   c.Assert(foo, IsTrue)
>   c.Assert(bar.SomeFunc(), IsDirectory)
> 
> 
> I know that Roger generally disapproves and has been including the
> checkers package normally.  This would make the above:
> 
>   c.Assert(foo, checkers.IsTrue)
>   c.Assert(bar.SomeFunc(), checkers.IsDirectory)
> 
> 
> What I don't want is arbitrary changing of the imports as different
> people touch various parts of the codebase into their preferred format.
> 
> I'd like to get a team agreement on what approach people are happy with.
> 
> I'm happy to go with a majority decision either way, but I'd like the
> team to decide.  If we don't get a quorum of response (for whatever
> value that may be), I'm going to defer to William as tech lead.
> 
> Cheers,
> Tim
> 



More information about the Juju-dev mailing list