Why not fmt go test output?

<p>The go test output would be a lot easier to read (IMO) if it test function names were aligned, much like gofmt treats struct definitions. Here&#39;s what it normally looks like:</p> <pre><code>=== RUN TestGroupContextListings --- PASS: TestGroupContextListings (0.00s) === RUN TestIdentifyCompletedTasks --- PASS: TestIdentifyCompletedTasks (0.00s) === RUN TestIdentifyStalledProjects --- PASS: TestIdentifyStalledProjects (0.00s) === RUN TestIdentifyFinishedProjects --- PASS: TestIdentifyFinishedProjects (0.00s) PASS ok github.com/blahblah/blah 0.003s </code></pre> <p>Here&#39;s what it could look like:</p> <pre><code>=== RUN TestGroupContextListings --- PASS: TestGroupContextListings (0.00s) === RUN TestIdentifyCompletedTasks --- PASS: TestIdentifyCompletedTasks (0.00s) === RUN TestIdentifyStalledProjects --- PASS: TestIdentifyStalledProjects (0.00s) === RUN TestIdentifyFinishedProjects --- PASS: TestIdentifyFinishedProjects (0.00s) PASS ok github.com/blahblah/blah 0.003s </code></pre> <hr/>**评论：**<br/><br/>andyjeffries: <pre><p>Personally I just tend to use <a href="http://goconvey.co/">http://goconvey.co/</a> even with normal tests</p></pre>mdwhatcott: <pre><p>Yeah, I&#39;m somewhat partial to that project as well :)</p></pre>mwholt: <pre><p>+1 for the irony.</p></pre>space-llama: <pre><p>Comment upstream on the mailing lists and optionally submit a patch. Or you could write an awk script to parse and format the output for you, then pipe go test results through it. You have options. </p></pre>mdwhatcott: <pre><p>Yeah, I think I will comment on the mailing lists. Every time I try to get through the contribution guidelines/processes I find myself wishing I could just submit a pull request on the github repo. #lazy</p></pre>space-llama: <pre><p>Github is a pretty garbage place to do a real code review for such a serious project. The song and dance of contribution guidelines is just to keep people honest and accountable. I like to frame it as: If you&#39;re not willing to fight for your change, is it really that important?</p></pre>mdwhatcott: <pre><p>Thanks for the ideas, BTW.</p></pre>eXeC64: <pre><p>This is just conjecture but it could be to make it easy to parse.</p></pre>mdwhatcott: <pre><p>Having some experience <a href="https://github.com/smartystreets/goconvey/tree/master/web/server/parser" rel="nofollow">parsing go test output</a>, I wouldn&#39;t go that far...</p></pre>mwholt: <pre><p>One guess is that the formatter doesn&#39;t know the names of all the test functions until after each test file is executed, so it may not know how much to indent. (But again, it&#39;s a guess, I actually have no idea.)</p></pre>mdwhatcott: <pre><p>I don&#39;t think the length of the test function has any bearing here. You just add 2 more spaces after &#39;RUN&#39; and it lines everything up.</p></pre>mwholt: <pre><p>Oh yeah. Right. I was thinking about the duration of the test for some reason.</p></pre>mdwhatcott: <pre><p>Gotcha.</p></pre>dericofilho: <pre><p>what you want is to run the output through <code>text/tabwriter</code> no?</p></pre>mdwhatcott: <pre><p>Sort of, except the go test output uses spaces, not tabs so I don&#39;t think text/tabwriter would do the trick here, but that&#39;s the idea yes.</p></pre>mdwhatcott: <pre><p><a href="https://github.com/golang/go/issues/10594" rel="nofollow">Created an issue</a> on the github repo. It&#39;s been included in the Go 1.5 milestone. </p></pre>