Recursive testing with 'go test'

[Boris Solovyov]

Hi all,

Here is shell script I use to test everything in source code directory.

#!/bin/sh

find . -name '*_test.go' | while read file; do

n=$(dirname -- "$file")

echo "$n"

done | sort -u | while read d; do

c=$(pwd)

cd "$d"

go test -i

go test

cd "$c"

done

As far as I see, 'go test' does not do this functionality for me, unless I miss it. It could be nice to have it added, do you agree? Something like "go test -r".

[Francisco Souza]

go test -i ./...
go test ./...

--
~f

[Boris Solovyov]

Thank you! Maybe the maintainers can add that to output for "go help test". It is currently hidden feature IMO.

On Fri, Dec 28, 2012 at 1:22 PM, Francisco Souza <f...@souza.cc> wrote:

On Fri, Dec 28, 2012 at 3:56 PM, Boris Solovyov
<boris.s...@gmail.com> wrote:

[bryanturley]

???

go help test

<cut 40-50 lines or so>
    -i
        Install packages that are dependencies of the test.
        Do not run the test.    <--- SLIGHTLY important for this discussion
<cut the rest of the lines>

Notice the "Do not run the test".
I use this nearly every day and it does not run the tests it recompiles referenced packages.

[Patrick Mylund Nielsen]

The ".." and "..."

--
 
 

[bryanturley]

On Friday, December 28, 2012 1:13:04 PM UTC-6, Patrick Mylund Nielsen wrote:

The ".." and "..."

Oh really ... does something special?
He typed "go test ./..." which didn't make sense to me so I assumed it was a typo for "go test ../.."
Perhaps it should be changed so that it doesn't appear to be a typo to others?

That is useful.  I was wondering why this didn't already exist just in the form of the aforementioned -R or similar flag never would have guessed "..."

[minux]

Maybe we do lack documentation on the 3-dot import path feature, but

I don't know how to better document it.

Have you read output of 'go help packages'? It says:

An import path is a pattern if it includes one or more "..." wildcards,
each of which can match any string, including the empty string and
strings containing slashes.  Such a pattern expands to all package
directories found in the GOPATH trees with names matching the
patterns.  As a special case, x/... matches x as well as x's subdirectories.
For example, net/... expands to net and packages in its subdirectories.

[Francisco Souza]

I read it 7 times, but I didn't understand your message. I also
re-read my message multiple times, but I wasn't able to find where it
said that -i flag is used for running tests.

Boris started the thread with an eleven lines shell script for running
tests recursively, I replied with two commands that when used
_together_, do the same thing (although not in the same order).

--
~f

[bryanturley]

Yeah could just be me, but "x ./..." still looks like a typo for "x ../.." to me.
Perhaps an example of using it in go test in the go help test would work
And on the -i thing in go help test I forgot i was on tip it may not be in go 1.0.3's version of the same.
 

[minux]

go test -i is fully supported in all of Go 1.0, and there aren't major changes to it in

the tip (only several bugfixes and one fix related to the data race detector).

[bryanturley]

Yes, I was talking about does it show up in the text of "go help test".
I told them it did then I realized I was on tip and not go1.0.3 so I am not sure if it does there.

[Rodrigo Kochenburger]

Do a "go help packages" and it will explain why its "./..".

go help test mention it in the end: "For more about specifying packages, see 'go help packages'.", but I agree its little hidden

[Dougx]

I just couldn't figure this out either and was busy writing a python script for doing this, confused why go test seemed to lack such obvious built in functionality when I found this thread.

It would be really useful to add something like this to go help test:

Where 'packages' is a list of packages to test conforming to the same standard as the import function (including the recursive '...' wildcard).

For more about specifying packages, see 'go help packages'.

~

Doug.

[Nate Finch]

Yeah, I couldn't find it either. I think the ... syntax should be moved up to the top of the packages section, since it's so useful, plus it fits in well with the description of . and .. at the top.  being buried near the bottom is not a very good place for it, IMO.

[Dave Cheney]

> Yeah, I couldn't find it either. I think the ... syntax should be moved up
> to the top of the packages section, since it's so useful, plus it fits in
> well with the description of . and .. at the top. being buried near the
> bottom is not a very good place for it, IMO.

Hi Nate,

This sounds like a great place to get started as contributor,
http://golang.org/doc/contribute.html.

Dave

[Dawid Polak]

I think it's (the 3 dot things) absolutely not intuitive. 

1. in go help test should be clear information about that. 
   
2. new flag (for example -r   --recursive ) could make it much easier to document and find

But thanks for this information - this is the first place where I found info that 3 dot allow recurrent test

[sjev...@gmail.com]

I found this command:

git test github.com/user/repo...

three dots at the end of the repo link does the magic