<p>I wonder why there is no builtin command to run all tests in a project. Using <code>go test ./...</code> is in my opinion too verbose/much to type and not very go-like.</p>
<p>The current default behavior of running only package-local tests is not intuitive. I would expect that <code>go test</code> would run all tests of a project and that something like <code>go test -package</code> would run all tests of a given package. Beside of that, there should probably be a way to run tests of used libraries as well, maybe something like <code>go test -all</code>.</p>
<hr/>**评论：**<br/><br/>faiface: <pre><p>There is no project in Go, there are only packages. Sub-packages don't exist. So it makes complete sense that go test runs the tests of the current package.</p></pre>daenney: <pre><p>Though the behaviour makes sense when you're aware of the "there's only ever packages" it is rather confusing if you come from any other language. There's a reasonable expectation that when you run <code>invocation of test runner</code> it will run all tests from the current root and recurse down.</p></pre>Paradiesstaub: <pre><p>This makes no sense. If there is a new Go user on let's say Windows (non Unix), how do you tell him to test his code changes on a bigger project? When the answer is, go and google or test every package by hand, Go IMHO fails.</p>
<p>Example2:<br/>
I write & test all my code on Linux. Right now, if I would like to check if one of my programs run on Windows too, I would have to google, to figure out how to tell the Windows shell (what ever the name of the default shell is), how to run all tests of my application.</p>
<p>It is strange to have a programming language which ships – code wise – with good testing support, but than "forgets" a command to run all tests of your application.</p></pre>hipone: <pre><p>I think you're creating artificial problems.</p>
<p><code>go test ./...</code> or <code>go test github.com/you/repo/...</code> works the same on Windows as on Linux.</p></pre>Paradiesstaub: <pre><p>I tried to point out that relying on a thirdparty tool (the shell) seems like a bad idea for such a general task. Also there exists more than one shell.</p>
<p>From your answer I would still not know if it works with cmd.exe or only with PowerShell. Also why not write a Makefile – like we used to do – since thirdparty tools are needed, why not stick with one that exists since a long time?</p>
<p>I love a lot of things about Go, but some decisions are – from my point of view – just wrong.</p></pre>hipone: <pre><blockquote>
<p>I tried to point out that relying on a thirdparty tool (the shell) seems like a bad idea for such a general task. </p>
</blockquote>
<p>Are you trolling? <code>...</code> is expanded by the Go toolchain, not the shell. Show me a shell that expands <code>...</code>.</p></pre>parnmatt: <pre><p>Zsh can do, at least in my Prezto configuration, as I type <code>...</code> it expands in line to <code>../..</code></p></pre>hipone: <pre><p>Still ../.. is not how Go expansion of ... works. I should be more precise with my question.</p></pre>parnmatt: <pre><p>I am aware, but that is a shell which can expand and may not have the desired affect with Go. </p></pre>Paradiesstaub: <pre><blockquote>
<p>Are you trolling?</p>
</blockquote>
<p>No</p>
<p>If no shell expansion is used here, why can't we have a flag for it? <code>./...</code>is quite cryptic. This is a serious question.</p></pre>hipone: <pre><p>How would you rewrite the following to use your flag instead of ...?</p>
<p>go test pkg1 pkg2 project1/... project2/... pkg3</p></pre>Paradiesstaub: <pre><p>Most programming languages only allow to test one project at a time, and I think that is what Go should do, too. What's the use-case for multi-project testing?</p>
<p>That's how I think it should be:</p>
<pre><code>go test # test the project
go test -package pkg1 # test package(s)
go test -all # test project and all of its dependencies
</code></pre>
<p>This is maybe more compatible with the current logic:</p>
<pre><code>go test -project # test the project
go test pkg1 # test package(s)
go test -all # test project and all of its dependencies
</code></pre>
<p>The <code>./...</code> notion should be removed, because it is not intuitive.</p></pre>hipone: <pre><p>So you want to cripple flexibility just to force your argument? Running multiple go commands has an overhead that single one does not have - if the packages being tested have the same deps they need to be parsed multiple times, instead of just once with single command. </p>
<p>Sorry, but I do not treat the "most languages" argument seriously.</p></pre>Paradiesstaub: <pre><p>Please calm a bit down. My point-of-view is that in the end, the programmer is writing an application and creating for it a project/folder. Tests are there to support him to do the job right. As such, it should be easy to run tests. I think that the current solution is usability whise not good, and missleadingly thought the current solution would also depend on shell expansion (which it does not) -> the usability argument still stands.</p>
<p>I don't see why argumenting that most other languages see the world from a project point-of-view would be a non-argument, since it is probably what someone comming to Go would expect. Since Go is the only language I know that choose to view the world from a package point-of-view, it would be intresting to know why.</p></pre>
