testing (was Re: Making juju work better with gccgo)

Tim Penhey tim.penhey at canonical.com
Sun May 18 21:40:11 UTC 2014


On 16/05/14 22:55, John Meinel wrote:
> FWIW, I wrote this little bash function and put it in my ~/.bashrc
> function gotest {
>   p="-gocheck.v"
>   f=""
>   if [ -n "$1" ]; then
>       if [ "$1" = "-r" ]; then
>           p="./..."
>       else
>           f="-gocheck.f=$f"
>       fi
>   fi
>   go test $p $f && go test -compiler=gccgo $p $f
> }
> 
> That lets my write:
> gotest
> gotest -r
> and
> gotest justOneSuite
> 
> I'm sure something better could be done, but that makes things
> immediately useful.
> The compile time is noticeably slower at getting the tests running (so
> this slows down iteration >2x), but until gccgo is ironed out it is
> probably still worthwhile.

I think it would be good if someone wrote a simple juju plug-in.

I toyed with this idea so it would give a similar feel.

We have hacks around hiding the log for failed tests so we can easily
see what failed, and dealing with other flags.

I thought we could have the plugin also emit the subunit output format
as an option for plugging into other tools like lifeless's test repository.

Main thing for me though was:
 * a simple capture of the log output
 * list the failing tests at the end so I don't need to go searching up
 * elapsed time
 * simpler way to execute one test so I don't need to type the gocheck
flags.

Tim

> 
> John
> =:->
> 
> 
> On Fri, May 16, 2014 at 6:53 AM, David Cheney
> <david.cheney at canonical.com <mailto:david.cheney at canonical.com>> wrote:
> 
>     Thanks Tim,
> 
>     I think we're in the position that even if you don't use gccgo for
>     your own development (understandable, it is slower), now that we have
>     platforms we support in Trusty that must use gccgo, armv8 and ppc64el,
>     for any new development, the code has to pass under both compilers.
> 
>     This is a bit of a bummer, but at least if you are running trusty on
>     your development environment, you have all the bits you need[1][2].
> 
>     Running tests, for a single package then becomes
> 
>         go test && go test -compiler=gccgo
> 
>     With respect to the whole Juju test suite, even after months of work
>     there still remain a few tests which do not pass under trusty, these
>     are tracked with bugs in lp, just look for the gccgo label if you find
>     yourself at a loose end.
> 
>     Cheers
> 
>     Dave
> 
>     [1] Prior to trusty, you'd probably be using gccgo-4.8, which is not
>     of acceptable quality for use with Juju.
>     [2] If for some reason you don't want to upgrade to trusty, we may be
>     able to ask Doko for a backport of gccgo-4.9, but really, just upgrade
>     to trusty.
> 
>     On Fri, May 16, 2014 at 12:44 PM, Tim Penhey
>     <tim.penhey at canonical.com <mailto:tim.penhey at canonical.com>> wrote:
>     > I realise I left this bit hanging:
>     >
>     > On 16/05/14 14:41, Tim Penhey wrote:
>     >> A key issue that Dave and I have been poking with a stick is the test
>     >> suite for juju/errgo, as it had some failures with gccgo (all passed
>     >> with gc).
>     >
>     > In the end it had to do with the runtime.Caller method for stack
>     > analysis, and the synthetic methods that gccgo was creating.  The
>     > solution was simply enough to convert the tests to use gocheck,
>     that way
>     > the synthetic methods that were being created are higher in the stack
>     > that we ever look in the tests, and it is all good.
>     >
>     > Tim
>     >
>     >
>     > --
>     > Juju-dev mailing list
>     > Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     > Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
>     --
>     Juju-dev mailing list
>     Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 




More information about the Juju-dev mailing list