"warning no tests to run"

[roger peppe]

On 29 August 2013 17:28, Gavin Panella <gavin.panella at canonical.com> wrote:
> On 29 August 2013 15:45, roger peppe <roger.peppe at canonical.com> wrote:
>> On 29 August 2013 11:09, John Arbash Meinel <john at arbash-meinel.com> wrote:
>>> Namely, "go test -gocheck.v ./..." doesn't *actually* run the tests in
>>> any subdirectories.
>>>
>>> The specific problem is how the arguments get evaluated, but we don't
>>> have any workarounds for it that I know of. (You just don't pass
>>> - -gocheck.v to ./... is the only workaround I have.)
>>
>> It's not a bug, it's a feature! (well, it's documented anyway).
>> From "go help test":
>>
>> "If the test binary needs any other flags, they should be presented after the
>> package names. The go tool treats as a flag the first argument that begins with
>> a minus sign that it does not recognize itself; that argument and all subsequent
>> arguments are passed as arguments to the test binary."
>>
>> That's because in general it's not possible to distinguish test
>> binary arguments from test flags - there's no way that
>> go test can know that --gocheck.v doesn't take an argument,
>> for example. This is the usual problem with command-line flag syntax - it's
>> a context-sensitive grammar.
>
> That's a bit of a clusterf**k :) It is *way* too easy to make this
> mistake, it's not immediately obvious that the mistake has even been
> made, plus the solution is hard to derive.
>
> I can think of two options to make this less likely to happen to
> someone else:
>
> - Change gocheck.v to not absorb an argument, so that "./..." will
>   either be used correctly or cause something to choke, instead of
>   passing silently into the void.
>
> - Change gocheck.v to insist upon "true" or "false" as arguments, so
>   that it rejects things like "./...".

-gocheck.v does not in fact absorb an argument, but something we could
do is barf if flag.NArg() > 0. I think that's a good plan actually - I can't
think of any immediate down sides (we might need to fix some
recursive tests though).

> I'll look into these.

Thanks!

>> I think:
>>
>>     go test -v ./... -gocheck.v
>>
>> might be what's needed here
>
> It's odd that both verbose flags are needed, but that's just a niggle.

Yeah, that's a consequence of using nested testing frameworks
(gocheck within standard go testing).