"warning no tests to run"

[Gavin Panella]

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 "./...".

I'll look into these.

>
> But it does show the workaround:
>
>     go test ./... -gocheck.v
>
> ... not that the -gocheck.v flag helps in this case, because
> go test only prints test output for failing packages by default.
>
> 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.

> (assuming you really want to see all that
> output - personally I think that's more verbose than generally needed,
> and is likely to hide the output from any failing tests).

It's fairly useful to have a log of every test that's run in a landing
robot, for example.

I think this Makefile - and the one in juju-core - is as much about
being living documentation as being a tool. We can all use our own
preferred flags with `go test` and whatnot, so that it's verbose by
default doesn't matter much.

(It's useful to be able to say that the landing robot need only run
`make check` before landing. Of course, if we were evil, we could
comment out the command in the check target to allow us to land
anything at all, but we have revision control and long range weapons
to deal with that.)